[Helma-user] managing helma collections
Joshua Paine
joshua at papercrown.org
Tue Aug 7 18:56:11 CEST 2007
tobias.schaefer at orf.at wrote:
> with getOrderedView do you refer to the already built-in helma method
Yes. I was trying to make clear what existed already so that I could say
how my plan would match/not match the existing function. My hypothetical
new method should have a new name, because it's not 100% compatible.
Let's call it getSqlView for the moment. I was thinking that was an
excessively comprehensive-sounding name, but I've just thought of an
improvement to my plan that would make most of what that implies reasonable.
> helma's getOrderedView currently has some limitations which make it
> impossible to use ordering on tables defined via additionalTables in
> a type mapping [1].
Right. (BTW, Re: your bug report, I don't know that this is the case,
but getOrderedView certainly *could* be faster and more memory efficient
than list().sort() because it's only comparing simple properties so it
doesn't need to run a user function for every compare and even though it
has to read every object, it doesn't have to keep more than the id and
whatever properties are being sorted on in memory.)
> It's a great strength of helma to update cached collections
> accordingly. whenever i ran into a sync problem here it got
> really confusing.
I don't know enough Helma internals (indeed, very little) to know how
this sort of thing is managed in general. Since the SqlView (formerly
the "proxy object", still acting like a proxy) uses the built-in Helma
methods of retrieving objects, it would automatically notice any object
updates (b/c the updated object would be returned from getById) and
deletions (b/c getById would fail for deleted records) that Helma knows
about. Inserts, however, would not automatically be reflected in the
ordered list because the whole point is that we're keeping only a
partial list of IDs and not the whole set of objects in memory. It's
probably possible to hook into Helma in some way so that the SqlView
could be notified of inserts, but I'm not sure what the desired behavior
would be (e.g., do we change the set while we're looping through it?).
And again, if you want the DB to do the sorting (which is necessary for
speed and memory efficiency) it's impossible to make only a small
adjustment to the SqlView's internal list when a new object is
added--the SqlView would have to get its entire list from the DB again.
In most cases that wouldn't be too slow, but I would hate to make it
automatic and setup for a pathological case where a complex view ends up
being recreated over and over when it's not needed.
More later on my updated plan. Probably requires a little more Java
hacking in the new version, but still should be pretty straightforward,
and it would give you the equivalent of DB-powered getOrderedView and
also what some other folks have asked for, which is essentially
arbitrary queries that still use the Helma objects and object cache.
--
Joshua Paine
Chief Tower Builder
LetterBlock Software
http://letterblock.com/
More information about the Helma-user
mailing list