Norbert,

you are right, I should have given an example of what I mean.

So here is one:

If you serialize an object graph to, say, json and store it in a NoSQL DB, you need to decide how "deep" you serialize your graph into one djson document and how to build up segments of your graph that need to be serialized separately, like for an equivalent of an 1:n relationship. Exanple: an Order contains OrderItems, each of which reference a Product. But the Product can be referenced from many OrderItems. So you need to "cut off" parts of your model to serialize them separately. And you need a way to save the "reference".

One of the next questions then is "what if I delete a Product?". What happens to the OrderItems or InvoiceItems and so on?

None of these problems are unsolvable, but these problems need to be addressed either in your persistence framework on top of a NoSQl DB or in your application code. In Relational DBs, they've built solutions for these problems before you and I were born ;-) I am talking of foreign keys, referential integrities and normalization. To my knowledge, these have not yet found their standardized counterparts in NoSQL DBs. So NoSQL can be a good solution for many problems, but they can also be bad for many others.

I am not saying anything new here. This debate has been going on for decades already, and much more clever people than me have made good points for both sides over the years now.

You also asked for examples for problems you get from using Glorp.

One of my biggest concerns is that it can be hard to model an m:n relationship where one or both sides of the relationship are abstract superclasses (or even concrete ones with multiple subclasses). It gets even harder when you want to be able to associate an object (like a Category or Tag) to "anything". This really is hard or involves some additional coding on top of the persistence framework.

Glorp does miss one feature painfully: The ability to map classes with subclasses that spread over three or more "subtables" for the subclasses. This one is hard to explain: if you have a superclass "Vehicle" with two subclasses "FlyingVehicle" and "DrivingVehicle", both of which have subclasses, there is no support for a model which has tables on the "FlyingVehicle" or "DrivingVehicle" level. You must model your DB in a way that there are all attributes in a "Vehicle" table or in the "Car", "Train", "Spaceship" and "Kite" tables. This really is a pity and I don't think anybody is working on changing this any time soon.

Does this explain what I mean?

Joachim
��

Am 25.04.14 08:41, schrieb Norbert Hartl: