When you create a MeshObject, it initially does not have a type. That means it can’t have properties and cannot participate in most relationships. Only once you bless it with a type (or several types) does it carry properties.

Over the life of a MeshObject, it can be blessed and unblessed many times. This means that almost by definition, application code using the MeshObject cannot, a-priori, know what type(s) it has. It also means that most application code working with the MeshObject simply treats it as a MeshObject, and nothing more specific. That is clearly weak typing in action.

However, if you know what type a MeshObject has (e.g. because you asked it), you can move over into strongly typed mode.

For an example, let’s assume there is an EntityTypecom.example.model.CustomerModel.Customer.Then you can do this:

The instance called strongly is now a strongly typed MeshObject. It is valid for as along as the MeshObject exists and is blessed with the Customer type. (Internally, the strongly typed instance is a different Java instance than the MeshObject instance; this is necessary due to the limitations of Java. But semantically they are the same, e.g. their property values are always the same.)

InfoGrid V1.x was only strongly (and statically) typed, like Java itself. Dynamic typing and this ability to choose between strong and weakly typed access, depending on what makes more sense for any particular piece of application code, is clearly a great improvement.

Good introduction to MongoDB at Linux Magazine. It makes the case for post-relational web application architectures quite well:

Web applications and traditional relational databases are nearing an end to their tumultuous relationship. For over a decade now, most Web applications have been built on top of relational databases, with various layers of indirection to simplify coding and boost the productivity of developers. For every Web programming language, there are any number of object-relational mapping (ORM) choices, each with pros and cons, yet none good enough that a developer can forget about SQL or ignore protecting the database. Moreover, as Web applications grow more complicated and sites need to be created faster, adapt instantly, and scale massively, these old solutions are no longer satisfying the demands of the Web.

There are a number of different projects working on new database technologies, all of which forego the stalwart relational model. Relational databases are difficult to scale, largely because distributed joins are difficult to perform efficiently. Further, mapping from the many popular dynamically-typed languages to SQL is complicated, inefficient, and time consuming. While often called the â€œNoSQLâ€ movement, the need for new technologies is caused by the relational model, rather than SQL.

Beyond the relational model, there are a number of data model choices: key-value stores, tabular databases, graph databases, and document databases…

InfoGrid is built around a graph database in this terminology. Except of course, that by virtue of the Store abstraction, InfoGrid can delegate to virtually any kind of database. InfoGrid does not contain a database itself. We believe this separation of concerns makes it easiest for developers to benefit from the high-level services that InfoGrid offers, while still being able to choose whatever storage technology they prefer.

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:

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.