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:
Am 25.04.2014 um 06:51 schrieb Joachim Tuchel <jtuc...@objektfabrik.de
<mailto:jtuc...@objektfabrik.de>>:
Hi,
We're using Glorp on VA ST for kontolino.de <http://kontolino.de>. It
is an active project in the sense of somebody is taking care of bugs.
The lead developer(s) work(s) for Cincom - and Cincom uses Glorp as
supported component of CST. Instantiations also provides Glorp with
VA ST and supports it. Glorp is very stable and is not moving fast,
which is not a disadvantage for a production system. Features are
being added and bugs are fixed.
Re: Pharoers do NoSQL: judging from the discussions on this list and
others, you have to be careful what you need. To me it seems many
developers want features from relational DBs and hammer them into
their applications with brute force. The first wow! soon gives room
to a lot of problems that have been solved in relational DBs three
decades ago.
I think such a statement should be based on an example.
But it is true that o/r mapping is not always fun. It can force you
to make decisions about your model that look strange from the object
perspective.
Agreed. And especially in the context of O/R I'm curious what will be
your example to prove your point above.
Couldn't resist,
Norbert
I'd either go full objects (gemstone, magma) or relational for my
typical projects (business apps).
Hth
Joachim
Clément Bera <bera.clem...@gmail.com <mailto:bera.clem...@gmail.com>>
schrieb:
Hello,
I think Glorp is used with DBXTalk for relational databases by
multiple people.
Usually, with Pharo, people use as a persistance layer either MongoDB
with the frameworks MongoTalk/Voyage.
Gemstone is also used quite often for large scale application but
Gemstone is not free.
Regards.
2014-04-23 20:34 GMT-07:00 Pablo R. Digonzelli <pdigonze...@gmail.com
<mailto:pdigonze...@gmail.com>>:
Hi all, can someone tell me if glorp is active there ar is using
glorp or other persistence framework in production projects?
Tia
****
------------------------------------------------------------------------
*Ing. Pablo Digonzelli*
Software Solutions
IP-Solutiones SRL
Metrotec SRL
25 de Mayo 521
Email: pdigonze...@softsargentina.com
<mailto:pdigonze...@softsargentina.com>
pdigonze...@gmail.com <mailto:pdigonze...@gmail.com>
Cel: 5493815982714
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
