Hi Norbert,
I am way too old for holy wars ;-)
So in essence, we are both saying that hammering objects into either an
SQL or NoSQL database can be hard and both approaches have negative
drawbacks as well as plusses.
I didn't come up with Transactions because they also can make things
hard. See the atomic counter question from a few days ago.IN ORMs you
usually end up with both image-side and database-side implementations of
Transactions, and this can be helpful and complicated at the same time.
Sometimes you'd just like to save one object without saving lots of
associated ones from the same unit of work.
Does this all lead us to the object database grounds? Or is it all just
a debate of taste and faith? I am still wondering if my life would be
easier if I used an object database (Gemstone comes to mind, but also
Magma). And still I cannot find the final answer.
Maybe that is because I have some knowledge with ORM, but very little
with OODBMS.
No matter what, my initial point should have been that I think it is
naive to think that NoSQL DBs solve a lot of the problems you have with
RDBMS. They just don't address them, and if you don't see som eof these
problems in your domain, I guess you're best off using NoSQL.
ObjectID and stuff in mongo still means you have to make design
decisions and implement something to assign/retrieve those ids and store
them in places where you want to reference your objects. So you do a
subset of the bookkeeping that an RDBMS can do for you by hand. Is that
a fair way to put it?
You made a good point and I tend to agree to most of what you say.
Joachim
Am 25.04.14 10:35, schrieb Norbert Hartl:
Joachim,
thanks for your explanation. I appreciate that. I was thinking if it
is a good idea to write my mail. Usually this ends in a holy war which
I don’t want. Comments inline.
Am 25.04.2014 um 09:02 schrieb jtuc...@objektfabrik.de
<mailto:jtuc...@objektfabrik.de>:
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“.
You can do that in e.g. mongo as well. You just use on ObjectId as a
field value or you use a DBRef. Btw. what you describe is not 1:n but
m:n. An OrderItems can have n products and a Product can be in m
OrderItems.
One of the next questions then is "what if I delete a Product?". What
happens to the OrderItems or InvoiceItems and so on?
If you just delete it the collections will have a stale reference. I
think there is no universal answer to that even if it seems the
removal in the collection is that universal answer. If it is about
integrity you need one way to make it happen. Reestablishing of
integrity can happen on write time or on read time.
What will happen in a SQL context? You can’t delete an object that is
pointed to by a foreign key. What does it help then? Not taking your
business model into account you couldn’t do anything more to find out
where that reference is. That is probably the only point I wanted to
make questioning your last mail. If we take that scenario you can only
solve it if you take the problem one level higher (well, if you have
cascading deletes you may ignore it). So these problems tend to end in
the application logic. And that is what my experience tells me.
Database ensured integrity isn’t much of a help in many cases. So you
solve the problems in the application logic (knowing which things
reference what). Being there I see no big differences to using a NoSQL
database. In NoSQL those features are just not there per se. You have
to model it regarding your use case.
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’m questioning the use of each of those. As I said above I doubt
there are many use cases where foreign keys are the best way to go.
Btw. if you ever administrate a database and you have to recover after
a crash then you might have a different view on foreign keys because
they are able to make it close to impossible to load the data back.
Referential integrity is either done by the database by foreign keys
or in the application logic as I said above. The need for
normalization is heavily use case depend. It is nothing good per se.
So these are not good examples IMHO. I’m wondering you didn’t bring up
the only good reason for SQL databases (for most). For me this is
having atomic operations using transactions. This is the one case that
can drive you nuts if try to model something with a NoSQL database to
achieve it.
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.
Sure. But from time to time it is good to refresh the memory. And for
me you are clever enough ;)
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.
Yep. Dealing with these cases I learned that Objects and SQL databases
don’t fit together and why ORM cannot work. I mean Glorp is really
good at that by providing your use case with subclasses via virtual
lookups. I don’ remember how it works. It was like a descriptor with
candidate classes which lead to multiple lookups. I figured that out
while talking to Alan 8 years ago. I think I managed it by using a
three column m:n mapping table where you have the two ids and an
identifier that gives a hint which subclass/table it is to look into.
Anyway even if Glorp supported sublasses lookups it was a can of worms
to open. I once changed a single thing in my glorp descriptions and
then the login the web site took 1,5 minutes just because all the
magic in Glorp produced 432 database lookups initiate by a single
button click. You just try to force a schema (OO) onto a technology
(SQL) that does not support this case at all. It is an entity
relationship model where the entities are flat. Inheritance is not
part of the solution.
So the summary would be: A lot of people making big efforts to forcing
an object model into a technology that doesn’t support it just because
they want to have features like integrity you can establish in other
ways. This is why I don’t use SQL databases anymore until I have a use
case that does benefit from it.
Does this explain what I mean?
Yes and I hope I made point also very clear :)
Norbert
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 Tuchelmailto:jtuc...@objektfabrik.de
Fliederweg 1http://www.objektfabrik.de
D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
--
-----------------------------------------------------------------------
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
