> For example. When a player logs into the game. Should I get all
> properties from the DataObject once and store them in fixed
> fields? I could use a load() and save() method that communicates
> with the DataObject.
You should use DataObjects. Extracting all values out of them kind of
defeats the purpose of using an ORM. I strongly doubt that calling
"getX()" would ever become a performance bottleneck. But if it does,
IMO it is a much cleaner solution to further optimize DataObject
implementation instead of wrapping it with another layer that adds no
functionality.
E.g. you can have generate a "read-through" getters that cache a read
value in an ivar field, but still follow the DataObject contract - all
this can be done simply by modifying class generation template, and
without changing the public API of you concrete object.
We can talk about this in detail if this indeed becomes a problem.
> I'm also unknowledgable of how the values are being read. How
> they are cached. And if there is a difference between how values
> and lists used in many-relationships are stored.
Internally the difference between "simple" object properties and to-one
and to-many relationships is that relationships can be completely lazy
and fetched on demand. As discussed in another thread, "simple"
properties are initialized on object fetch.
On the other hand when you call a typical to-one getter (say
painting.getArtist()"), a returned object is "hollow", i.e. the object
is there, but its values haven't been fetched yet. The values will be
fetched whenever the first getter is called (say "artist.getName()").
Same thing with to-many - the list returned is not resolved until you
call "size()", "iterator()", "get(int)" or any such method that
requires to know the actual contents of the list.
Andrus
This archive was generated by hypermail 2.0.0 : Thu Jun 24 2004 - 11:33:35 EDT