On Monday 12 August 2002 10:50, Eduard Witteveen wrote:
> On Fri, 2002-08-09 at 16:30, Marcel Maatkamp wrote:
> > // virtual node -> real node
> > Enumeration e = tussenresults.elements();
> > while(e.hasMoreElements())
> > results.addElement(
> > this.parent.getNode(((MMObjectNode)e.nextElement()).getStringValue(type+"
> >.number")) );
> >
> > return results;
> > }
>
> This can produce a lot of select * from the database. Maybe we should
> change it to something like
> return ((MMObjectBuilder)getModule(type)).search("where number in (" +
> foundNumbers + ")"); ?
(the parent-call is now added in the method, not committed, only added locallly)
This call to search will expand itself to the (uncached) searchVector, which does
a 'SELECT * FROM "+getFullTableName()+" "+where" where where is the where-
clause.
The getNode() - method is cached, refering to org.mmbase.cache.NodeCache.
I prefer this because I expect the page/program to do a getValue on these nodes, hence
if they are in memory will speed up the phase afterwards.
> Or add a method 'List MMObjectBuilder::getNodes(List objectnumbers)',
> where the getNodes will return MMObjectNodes of the type(subtype) of the
> builder specified.
> The MMObjectBuilder can decide how to handle the request on the builder
> for the nodes. When a node is mentioned in the list and not in the
> builder, i think it is valid to throw an exception.
Which I prefer to let it call the getNode-method, which in effect is the same as what
I
propose above. You could argue that this would now be cachable, which would only
marginally speedup frequently reloaded pages, on the expence of having
another builder-cache which should be maintained by its nodes.
gr,
marcel
