Posted by
NorbertHartl on
Apr 08, 2010; 11:10am
URL: https://forum.world.st/Experiences-with-non-RDBs-tp1753935p1773869.html
On 08.04.2010, at 12:35, Friedrich Dominicus wrote:
> Norbert Hartl <
[hidden email]> writes:
>
>> - in OODBs this case is easy. The serialization contains everything
>> from the key-values and the class that they belong to. Sometimes the
>> data format on disk is the same as in memory so there is less to
>> do. The difference between magma and gemstone is that magma is an
>> addition to an image. That means you have your smalltalk image in
>> memory and than you have magma. With magma you define a persisted root
>> object, e.g. a Dictionary. Everything you attach to the Dictionary
>> will be persisted if you do a commit. Well, you need to do your
>> changes inside a transaction but there are always ways to make this
>> look nearly transparent. In gemstone everything is already persisted
>> including all the classes and objects. As soon as you attach a newly
>> created object somewhere that is already persistent it will be
>> persisted, too. The easiest way of handling your data is to keep an
>> instance variable in your class that holds the instances. Et voila,
>> that's all! All you objects are persisted. Speaking of seaside
>> gemstone can be used doing autocommits on a request basis so you don't
>> have to care at all about transactions. You just use your objects and
>> that is it. Querying is like using collections. If you need special
>> kind of querying either for your problem or performance you can
>> provide a special type of collection that is optimized for the problem
> Are there any examples around showing that?
The special collections? I don't know much because most of the time you don't need something special. The only thing that comes to my mind are the reduced conflict collection classes in gemstone that could be considered special. But basically you subclass a collection class that deals with a special implementation and then you just create that one instead to other.
>>
>> - In SQL databases the instance variables are mapped to columns of a
>> table or multiple tables and each row is an object. Relationships of
>> objects are handled by keys in the tables. A 1:1 relationships
>> contains a key of the relation source in the relation target table. A
>> n:m relationship needs an intermediate table that maps relation source
>> keys to relation target keys. Talking about inheritance this gets
>> easily complicated. Basically there are two options. You can solve it
>> like everyone would expect it, let's say more BNF like. You would have
>> a table A for class A and a table B for class B. Now in all tables of
>> objects that reference A or B you need an additional information which
>> class is meant: A or B. The tables than could be joint correctly after
>> evaluation the additional value. Another strategy is to do multiple
>> lookups until you've found the right value. The other approach is to
>> make one table that is a super set of all needed variables. The keys
>> are unique among all the subclasses and can be lookuped up more
>> easily. But you waste some space because a lot of the columns would be
>> empty. In any case you need to change your database schema if you
>> change your model. Joins and number of requests can grow easily so
>> that your application will be slowed down. Glorp gives you all of
>> these strategies if you want them. My personal advize would be to
>> avoid inheritance in that scenario completely or do only the simplest
>> cases possible. Relational databases and object oriented approaches
>> just don't fit together.
> Well that was what liked to get shown. I was thinking in the simples
> possible cases of inheritance and how "bad/good" that works with RDBs.
>
> So I wanted to know if someone has done some work on ORM to handle that
> with not too much pain on "my side".
>
Define pain! :) I used Glorp a lot and is good piece of software. It helps you a lot with these things. Well, it helps you as much as it is possible when dealing with RDBs. I could create most of the cases but then suddenly a login attempt to the website caused around 400 requests to the database just to show the first page. That's the point where it turns against you and you have trouble to look behind all that that was causing you less pain.
> I expected something like that. Either you build you stuff that it fits
> the RDB model or you better avoid RDBs. I have tried to figure
> that out e.g in Rails but it all comes short if "even" simple
> inheritance comes into play. You message just confirms this impression.
>
I think this is a more general rule. Things are made for a purpose. If you try to force them to fulfill a completely different purpose it probably won't work out. At least it will cause you pain.
> Any way my question still persists, are there anywhere examples on
> handling inheritance in ORMs?
I scanned my old archives but didn't find a good example at first glance. Maybe it is not in my repository because all the attempts weren't satisfactory at all. So I probably never committed one of the trials.
Norbert
_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users