Limitations

Limited Query Capabilities

Queries in D2 are not nearly as flexible or powerful as SQL queries. Too bad.

Cross-Entity Queries (Joins)

Because each indexer in D2 operates on only a single entity type, it is not possible to create a query that crosses the boundaries between entities on the fly (at query time). However it is possible to define an index on a method of an entity, and that method can fetch data from a related entity that has already been loaded into memory. Thus, if such a requirement is known ahead of time, a virtual field can be created and indexed referring to data in the related entity. Then, at query time, that field can be queried to achieve a virtual join. This process requires planning and is less flexible than SQL queries, but it is effective in many situations.

ACID vs. Performance

Once ACID capabilities are built into D2 (not implemented yet), optional ACID compliance will be possible if the underlying data storage system and indexer support this feature. However, this will likely come at the cost of scalability, speed, or both.

Automatic Lazy Loading vs. Easy Configuration

D2 does not currently support automatic lazy loading. It also requires you to manually add a variable of type “D2MetaData” to each of your root-level entities. These two requirements could be removed by adding a custom classloader which modifies D2 Entities as they are loaded, adding the required functionality. However, this would require manual configuration of the JVM to specify the custom classloader. This could certainly be considered if the community wants such a feature. It might be possible instead to create subclasses of entities instead of using a custom classloader, though this has its own trickiness and would only work for lazy loading and not for adding D2MetaData.