The Bless Relationships API

InfoGrid supports types on both nodes and edges, aka MeshObjects and Relationships. They are called EntityTypes and RelationshipsTypes, respectively.

Assume we have two related MeshObjects, each blessed with a (hypothetical) type Person. Like this:

MeshObject obj1 = ...;
MeshObject obj2 = ...;
obj1.bless( PERSON );
obj2.bless( PERSON );
obj1.relate( obj2 );

Now if we want to express that the second Person is the daughter of the first Person, we cannot do this:

obj1.blessRelationship( PERSON_PARENT_PERSON, obj2 );

because we don’t know, from this API, whether obj1 or obj2 is the daughter or the parent.

Instead, in InfoGrid, we have to explicitly specify the direction, and we do this by specifying the “end” of the relationship type instead of the relationship type for the bless operation, like this:

obj1.blessRelationship( PERSON_PARENT_PERSON.getSource(), obj2 );

Hopefully, the documentation of the parent relationship type in the model indicates the semantics of the source and the destination of each relationship type. These “ends” are called RoleTypes, by the way.

One nice side effect of this approach to the API is that it becomes quite straightforward to extend it if InfoGrid ever decided to support ternary or N-ary relationship types: Just pick a RoleType beyond a source or destination RoleType.

If you bless relationships from the HttpShell — the simplest way of manipulating the graph from a web application — you thus need to specify the identifier of the RoleType, not of the RelationshipType. By convention, the source RoleType of a RelationshipType with identifier ID is ID-S, and ID-D for the destination.

Tip: Always RelateIfNeeded when using HttpShell

The InfoGrid HttpShell is something rather amazing when creating web applications. With just a little bit of HTML markup, we can modify the graph of nodes and edges in the GraphDB any way we want, all without writing any handler code for it.

For edges, it understands the keywords:

  • relate
  • relateIfNeeded
  • unrelate
  • unrelateIfNeeded

Relate will fail if the two nodes in question are related already. And in practice, that turns out to be more common than one would assume; only blessing of the edge with the appropriate RoleType is often needed.

So here’s the tip of the day: unless there are good reasons not to, use “relateIfNeeded” and “unrelateIfNeeded” for your application code.

InfoGrid and Relational Databases

The other day I was asked:

Your pitch for InfoGrid really disses relational databases. But then, InfoGrid applications usually use MySQL (or PostgreSQL) to store their data. What gives?

To which I responded:

All the database vendors want you to store your data in their database, instead of files in the file system. But then, the databases themselves store their data as files in the file system. What gives?

This does not sound as contradictory. It’s fine that a database stores its data as files in a file system; it may or may not, as an application developer you really don’t care much. You care about the high-level facilities (such as SQL) that the database provides, because writing code against them is much easier and faster than writing against files (for many applications).

The InfoGrid argument is the same one, just one level up: It is much better the develop against the InfoGrid APIs than against SQL directly, because of all the high-level facilities that InfoGrid gives you. Here’s an example:

Try this with a relational database:

MeshObject employee = ...;
employee.bless( CustomerSubjectArea.CUSTOMER );

Your employee has just also become a customer, with all that this entails (e.g. participating in the relationship Customer_Places_Order, which you can’t as a mere employee). For more on blessing objects, see the documentation.

With raw SQL, you wouldn’t even know where exactly to start, but chances are you would have to redesign your schema, and write and update a whole lot of application code.