Over the past years, application development for big data management with NoSQL data stores has matured: Developers no longer need to code against proprietary APIs. Instead, object-NoSQL mappers introduce a desirable level of abstraction [15]. Like their counterparts for relational databases, object-NoSQL mappers such as Objectify [9], Morphia [8], or Hibernate OGM [5] marshal and unmarshal between stored entities and objects in the application space. Annotated Java classes, the object-NoSQL mappings, declare how objects are to be persisted as entities.
Going beyond this core business, Objectify and Morphia enhance a key feature of NoSQL data stores in agile software development: the schema-flexibility of NoSQL backends [7]. Let us consider a standard development environment with an editor (e.g., an IDE like Eclipse) and a code repository. The production environment contains a schema-flexible No-SQL data store, possibly offered as database-as-a-service (DaaS). A platform-as-a-service infrastructure (PaaS) takes care of the load balancing at runtime. As the data store does not enforce a schema, the entities stored by different releases of the application may differ in their structure. Nevertheless, the NoSQL data store is capable of evaluating queries over the structurally heterogeneous entities.
We now switch to a real-life example. Figure 1 visualizes schema evolution in the object-NoSQL mappings of the open source project ExtraLeague [3]. ExtraLeague implements a small website for managing company-internal soccer championships. This project is written in Java, uses Google App Engine (as PaaS) and Google Cloud Datastore (as DaaS) [10], as well as the object-NoSQL mapper Objectify. At the point of writing this paper, 9 contributors have collectively made about 700 commits to this project hosted on GitHub. The chart reads as follows. The x-axis shows the number of commits to the project, which may be interpreted as the progress in time. The y-axis shows the number of object-NoSQL mappings (i.e., the Java classes that de-Figure 1: Schema evolution in ExtraLeague [3]. { "kind": "Player", "id":
1, "name": "Gollum", "health": "poor" } { "kind": "Player", "id": 2, "name": "Bilbo", "health": 5 } { "kind": "Player", "id": 3, "name": "Frodo", "health": clare the current data model). Over time, the project grows to 13 mappings. Some object-NoSQL mappings are removed from the project, resulting in interim dips in the chart. At any point in time, the chart states how many classes remain unchanged ("Attrs not modified"). If a mapping contains at least one retyped attribute, it is flagged as such ("Attrs retyped"). Otherwise, if it contains at least one removed attribute, it is also flagged accordingly ("Attrs removed"). Finally, when attributes have been added, but none of the other cases apply, the mapping is flagged as such ("Attrs added"). Thus, we classify the object-NoSQL mappings by their most disruptive schema change.
In total, the object-NoSQL mappings have changed in 47 commits. When the object-NoSQL mappings change with a new release, this effectively amounts to a schema change. Yet rather than migrating all legacy entities prior to a release, legacy entities may be migrated lazily, when they are loaded into the application, one at a time. This is supported by several object-NoSQL mappers, such as Objectify.
Lazily evolving an entity by adding an attribute is generally a safe operation: When a legacy entity is loaded into the application, the attribute is added as the entity is mapped to a Java object. When the object is saved again, the entity is persisted with the new attribute.
However, when attributes are removed, renamed, or retyped, the object-NoSQL mappings may no longer be backwards-compatible with legacy entities. Accidental removal or faulty renamings of attributes lead to runtime problems, a topic we have addressed in an earlier paper on ControVol [2].
In this paper, we focus on attribute retypings, which also occur in Figure 1. Retypings can lead to 1. data loss (due to implicit type conversions), 2. runtime exceptions (due to type incompatibilities), and 3. confusing query results (due to the lack of standardization of NoSQL query languages). These runtime issues may only be sporadic: The production data store may contain only a small number of structural outliers that nobody in the development team is aware of. Yet this makes trouble shooting even more difficult. Therefore, systematic tool support is of the essence.
Contributions: In this demonstration, we present new ControVol features for (1) finding type mismatches in the evolution of object-NoSQL mappings, (2) addressing the subtleties that retyping can have on query evaluation in some NoSQL data stores, and (3) suggesting quick fixes so that developers may pro-actively address these problems. Our earlier demos of ControVol [1,11] showed how ControVol finds and fixes issues caused by the removal and renaming of attributes in object-NoSQL mappings. This earlier ver-sion would also warn when attributes were retyped, but then forced the developer to restore the original type. This effectively made it impossible to change attribute types. Contro-Vol, as presented in this paper, actually enables developers to change types in a controlled manner.
Videos and further information on ControVol are available at https://sites.google.com/site/controvolplugin/.
In discussing mismatched types, we focus on Java primitive types1 : Boolean, Byte, Short, Integer, Long, Float, Double, and String. ControVol may be extended to handle structured types as well.
We next consider the scenarios featured in this demo. Figure 2 shows player entities stored by different releases of an online role playing game. It also shows the object-NoSQL mapping of the current release. The object mapper annotation @Entity declares that player objects may be stored. Annotation @Id marks the unique ID among all players.
Our upcoming example illustrates how mismatched types can cause runtime errors. As runtime errors are particularly undesirable in web applications, the underlying problem should be addressed prior to launch. We then describe how ControVol finds and fixes these issues.
Example 1. The legacy entity for player Gollum in Figure 2(a) records Gollum's health as a String. Let us assume Gollum's player has been stored several releases back, when health was classified as "poor", "fair", or "excellent". Much has changed since then: The object-NoSQL mapping in Figure 2(d) expects to load a Double value. Thus, loading Gollum's entity will cause a runtime exception due to an unsuccessful type cast.
2
ControVol monitors code changes from within Eclipse to detect this issue at development time. To do so, ControVol accesses the code repository and compares different versions of object-NoSQL mappings. For instance, if ControVol detects the earlier declaration shown in Figure 3, then it warns about the type mismatch with the declaration in Figure 2(d). Note the warning symbol in line 10 of the screenshot, injected by ControVol. We discuss the second quick fix in greater detail. If selected, ControVol rewrites the class as shown in Figure 5: 2• The original health attribute of type String has been restored. Annotation @IgnoreSave ensures that the value is loaded from legacy entities, but not saved anymore. • The new health attribute of type Double has been renamed, so as not to conflict with the legacy attribute. • A method stub for migrateHealth has been generated.
Due to the Objectify annotation @OnLoad, this method is invoked whenever a player entity is loaded. The developers may now translate the value of legacy attribute health to a Double value within migrateHealth. 3
We next give an example of the effect that attributes with mixed value types can cause during query evaluation. out a runtime exception, since the Integer value is implicitly cast to Double (yet loss of precision is possible). However, as long as Bilbo's entity is not migrated, this type mix in the data store can produce seemingly confusing query results. For instance, evaluating the query SELECT id FROM Player ORDER BY health ASC LIMIT 10 on our entities from Figure 2 in Google Cloud Datastore returns Bilbo's ID before Frodo's. Yet Bilbo's health is 5, while Frodo's health is 1.2 This seems counter-intuitive given ascending sort. Worse, MongoDB returns Frodo's ID before Bilbo's for the same query.
2
This puzzling behavior is due to the lack of standardization in NoSQL query languages. In Google Cloud Datastore, all queries are evaluated over indexes. The indexes contain hierarchically sorted entries, with primary order on the value type and secondary on a type-specific ordering [4]. Let us consider the index capturing the entities from Figure 2, as well as a fourth player named Peregrin with id 4 and a Double health value of 9.9.
In displaying the index as shown in Table 1, we employ the visual notation from [10]: Google Cloud Datastore evaluates the query from Example 2 using an index containing the keys of player entities (consisting of the kind "Player" and the player id), and the values of their health properties. These are sorted in ascending order. The index entries are sorted, with Integer values before Strings, and further before floating point values.
health ↑ Player/2 5 Player/1 "poor" Player/3 1.2 Player/4 9.9 Now, retrieving all player IDs in ascending order of their health is conducted by a single scan over this index. Scanning the index from top to bottom retrieves Bilbo's ID, then Gollum's, Frodo's, and finally Peregrin's. To NoSQL novices, this may seem surprising, and understandably so: When the entities are loaded as Java objects into the application, Frodo's health value has type Double (due to the implicit type conversion on loading). This makes it particularly confusing why Bilbo with a health value of 5.0 should be sorted before Frodo with a health of 1.2. From the viewpoint of the developer, this is a puzzle that can only be solved by inspecting the raw contents of the data store.
Worse yet, this effect is product-specific: Table 2 captures the order in which MongoDB returns the query results. Here, the sort operator returns all numeric values before strings, and hence, a different result.
Thus, even when developers aim at platform independence by using object-NoSQL mappers, the implementation details of NoSQL data stores shine through. Since such effects can be easy to miss, we have set up ControVol to warn if a change to an object-NoSQL mapping might introduce mixed value types. This gives developers a chance to react, e.g., to identify these legacy entities and to eagerly migrate them to Double values. This can be done by writing custom code or using declarative, special-purpose schema evolution languages, c.f. [12,14]. Having made sure that incompatible legacy entities no longer exist, and having allowed the data store indexes sufficient time to be rebuilt (which happens in Google Cloud Datastore), the warning issued by ControVol may be suppressed.
The general outline for our interactive demo is this:
1. We introduce the typical setup for NoSQL web development: Developers write code in the Eclipse IDE, manage its versions in Git, and regularly deploy the application to a PaaS framework (Google App Engine). The application is backed by a NoSQL data store (Google Cloud Datastore). 2. We show common pitfalls in evolving the application code: Foremost, we focus on issues introduced by type changes in object-NoSQL mappings. We also demonstrate the earlier features of ControVol, such as finding problems caused by renaming or removing attributes. 3. We provoke various consequences of mismatched types: data loss, data corruption, runtime errors, and counterintuitive query results, as discussed in Section 2. Con-troVol then finds these issues and proposes quick fixes, which it carries out semi-automatically. 4. We further run ControVol on open source projects publicly hosted on GitHub, and thus, on real-life code. We discuss the impact of conflicting type declarations with our audience, as well as the tradeoffs between quick fixes.
When it comes to assessing the potential impact of Con-troVol, we point out two current trends: First, schemaflexible NoSQL data stores are gaining popularity [7], especially in agile web development: When projects undergo frequent releases and cannot afford downtime due to a release, NoSQL data stores can be suitable backends. Second, object-NoSQL mappers with support for lazy migration are gaining popularity. Among the currently popular libraries, there are Objectify for Google Cloud Datastore, and Morphia for MongoDB. The future roadmap for Hibernate OGM explicitly mentions similar plans for lazy data migration [6]. Thus, there seems to be a trend for vendors of object-NoSQL mappers to provide annotation-based support for data migration. Looking at both trends, we see a growing market for tools like ControVol, especially considering the gaping void when it comes to a tooling eco-system for NoSQL-backed application development.
ControVol was partly funded by CNPq grant 441944/2014-0. We thank Tegawendé F. Bissyandé from University of Luxembourg for suggesting to us to crawl GitHub projects. We further thank Uta Störl from Darmstadt University of Applied Sciences for sharing her insights on queries over mixed value types in MongoDB. Last but not least, we thank the anonymous reviewers for the careful reading of our paper and their helpful suggestions.