Ted Vinke wrote:
> there's no other nifty trick for NODE-fields to have access to ANOTHER
> field in a query (in this case, the 'defaultcontext'-field) than the
> number?
No, i don't think so.
> Example 2.
>
> <mm:listnodes type="mmbasecontexts" constraints="name = 'default'" max="1">
> <c:set var="defaultnodenumber"><mm:field name="number" /></c:set>
> </mm:listnodes>
>
> <mm:listnodes type="mmbaseusers" constraints="defaultcontext =
> '${defaultnodenumber}'">
> // now we can do stuff with our context
> </mm:listnodes>
>
> which seems two darn inefficient queries to get mmbaseusers with a
> certain defaultcontext of which we know only the contextname upfront.
Well, you could perhaps trust the caches here. Probably only seldomly
mmbasecontext objects are created or modified, so the result of the
query on it could, given appropriately large caches, nearly always be
fetched from memory rather then from db. If the general caches won't do,
I would go for some specialized cache (perhaps one is already in CCS?)
> Any suggestions or are my examples as good as it gets?
No, I think I don't know anything else. I can't even come up with easy
suggestion to make joining by NODE-fields possible, because AFAIK the
query-frame-work would completely dissalow that now.
The other solution would be support for inner-queries.
select .. from mmbaseusers where defaultcontext in (select number from
mmbasecontext where name = '..'), which perhaps could be a specialized
field-value-constraint accepting another query as argument.
But all that will probably not even appear in 1.8, if ever.
Michiel
--
Michiel Meeuwissen mihxil'
Mediacentrum 140 H'sum [] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
