August 29, 2007
Why Tree based entities make sense for XTP
Many caching systems today support flat data models or Tuples. A tuple is just an array of primitive types. A simplified view of the popular Map API is that each entity is simply an array of two fields, a key POJO and a value POJO. This, while simple, doesn’t reflect the real world. Most business entities are not flat; they are tree like graphs. Lets take an Order object.
Order: orderId, customerId, purchaseDate, Array(OrderLine)
OrderLine: quantity, productId
This is a really simple Order entity and you can see it isn’t flat. It’s a graph. The Order object has a reference to a customer and a collection of OrderLine objects. The OrderLine object has a reference to products. It’s still a single Entity but it’s a tree. If you try to squeeze this in to a single Tuple as some of the competition force you to then you’ll end up with a serialization nightmare at runtime because changing any part of it would cause you to reserialize the whole thing. You could break it up in to several Tuples but now you have to navigate the relationships by hand, there is no support for doing this easily.
ObjectGrid can model this entity pretty easily as follows:
@ManyToOne Customer customer;
@OneToMany Collection orders;
// composite key here
@Id int lineNum;
@Id Order order;
@Id int customerId;
@Id int productId;
This defines the Order Entity and provides ObjectGrid with all the metadata necessary to understand it. An important thing to notice is that the schema root is the Order object. This is the only way to do a find on this Entity. It defines the root of the graph. This is a much more natural way to interact with this entity than trying to squeeze it in to a tuple form that doesn’t understand relationships. If an application wants to make a new order then it just news one up and then persists it to the ObjectGrid. If an application wants to make a modification then just do something like this:
Order key = new Order();
key.orderId = 456;
Order order = em.find(key);
Now, just navigate from the entity root to the part of concern and modify it. Notice, ObjectGrid doesn’t use special key objects, an entity POJO works fine as a key as would any POJO that had the correct attributes marked as Id.
ObjectGrid doesn't store POJOs when you use entities like this. We store tuples. Each entity is converted to two tuples, one for the key fields and another for the value fields. Relationships are stored using the id's of the related object. ObjectGrid automatically converts from the tuple form to the POJO form when the application uses the EntityManager API. Of course, it's still a Map underneath and an application can if it chooses work directly with the Map APIs and deal with tuple keys and values. This is useful sometimes for performance reasons. Bijecting the tuples to POJOs and back again simply costs path length so we give you the option. Easy of programming versus performance and you can mix these styles within a single application to find the best development cost versus performance ratio.
ObjectGrid uses the key of the schema root to hash the Entity across the set of partitions in use by the grid. The entities which are not schema roots can only be accessed from a remote grid client by first finding a root entity and then navigating. This means that such an Entity naturally fits in a single partition and thus meets the usual XTP criteria as discussed before.
To summarize here, entities in the XTP sense don’t usually map onto a tuple. However, entities can be decomposed in to tuples as seen here in a natural way.
August 29, 2007 | Permalink