|
|
Hi,
I'm investigating a possible shift from Lens to Glorp for object
persistency.
I have already browsed through the Glorp code and stepped through some
query building methods & transaction commits to get a basic
understanding of how things work under the hood. However, these were
based on very trivial objects. I would like to know some more things
without actually delving into the code.
When I was at the Cincom conference in Frankfurt, Alan Knight already
provided clear answers to some of the questions I have. But I still have
some extra questions. Instead of putting them all in one mail, I'm going
to send several mails with each one containing a single question. So
actually this mail is some sort of 'warning' mail: don't delete all
these 'Glorp-development' mails, your mailbox is not being spammed !
Instead, if you can answer some of these, it will be highly appreciated.
Thanks in advance,
Mark
-- some additional information --
For those that didn't attend the Glorp BOF session at the Cincom
conference in Frankfurt, these were the things I asked Alan.
Q: How does Glorp map object hierarchies onto tables ?
A: The reply was that this was one of the 'weaker' points of Glorp.
Glorp supports 2 kinds of mappings. The first one being one table that
contains the union of all fields of every class in the hierarchy. The
2nd one has a separate table for each concrete class in the hierarchy. I
asked if there was mapping to a database structure that mimics the class
hierarchy in the image (i.e.: a table for each class in the super class
chain), but this does not exist at this time. Alan replied that he
didn't expect it to be very difficult to make it so. I think a
requirement for having this might be 'partial loading' of objects which
I address in a separate email.
Q: Does Glorp have builtin support for a 'stub' database, ie: an 'in
memory' database in smalltalk that keeps track of objects
created/changed/deleted in collections stored in the image and that
performs queries on these collections. The reason for it would be that
it could make my tests run faster because there would be no database
connection overhead.
A: It is not available, but, since queries are actually smalltalk
blocks, it may not be totally impossible to make a thing like that.
Q: Lens offers the possibility to create methods that can be used in
queries. For instance: If I have a method
Book>>hasTitleFilledIn
^self title notNil
I can use this method in a query where I would say something like:
session retrieve: Book where: [:each | each hasTitleFilledIn]
Instead of having to write:
session retrieve: Book where: [:each | each title notNil]
Does Glorp support this mechanism ?
A: Glorp doesn't support it at this time. Alan was aware of its presence
in Lens and thought it was a pretty fancy thing, so perhaps it could be
added to Glorp some time in the future.
Q: Lens has support to keep 1-to-many relationship collections
automatically up to date in the image. F.e: When you delete a 'child'
object, it gets removed from the parent collection automatically. The
same for new objects & updates. Does Glorp do this also ?
A: Glorp never modifies anything of its domain objects. Keeping
domainmodels up to date is your own responsibility.
|
Locked
