Re: managing helma collections

[email protected] 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/