On Monday 12 August 2002 18:10, Eduard Witteveen wrote: > On Mon, 2002-08-12 at 17:46, Marcel Maatkamp wrote: > > > 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. > > If we would have a MMObjectBuilder.getNodes(List nodenumbers), the nodes > that are already inside the cache(nodeCache.containsKey(new > Integer(number))) can be retrieved this way. The othernodes _could_ be > retrieved by an search.
Nope, those have to retrieved with a MMObjectBuilder::getNode(). This will solve 2 'problems'.. 1) this is cached The getNode has its own cache. If you do a getNode(nr) it will come from cache or it will be retrieved from the database and put into this cache. The search would not. Netto effect: same as what you proposed above. Maybe a getNodes(list) is a method to be implemented, but if thats going to happen, it has to iterate through the nodenrs. and get the nodes by means of a MMObjectBuilder::getNode(). 2) inheritance Let me clarify this: Suppose you want to list node.related(Mediaparts) where Mediaparts are of type Audiopart or Videopart. A search would retrieve the Mediaparts (those are selected on otype) but a getNode would give the real type (say, Videopart). This solves the problem stated below (returnCorrectObjectBuilderTypes) very elegantly, which is thus not needed anymore. > This would mean that with just one more query, the node-cache can be > filled. This way it can be garanteed that the getRelatedNodes() will > produce 2 queries max, and will use the cache as much as possible > (unless the returnCorrectObjectBuilderTypes variable is turned into true > in MMObjectBuilder, which could result into 1 more query than your > proposed sollution). > > Should we put it into cvs, so that everyone can have a look at it?(if it > is really needed, we need to take some action..)
