Robin Lee Powell <[email protected]> writes:
> Imagine my surprise, then, to discover that the CLSQL version of
> find-persistent-objects totally ignores slot: and value:, instead
> pulling the entire table. Ewwww.
Actually this rarely happens in Weblocks; even when no custom query is
specified, we pull a limited range of usually 15 elements with the
:range argument, keeping the set order stable with :order-by.
> That seems bad to me; there should be a generic API for finding
> objects that have a particular value in a particular slot, since
> such a query should make sense no matter the backend.
Here is the problem: where do you stop? You can call the inability to
do any particular type of query a "bug". For example, one of my most
important on-query modifiers looks like this:
:where [and [= [pfs id] [alc pfs-id]] ;also autojoins the alc table
[between (get-universal-time)
[alc effective-date] [alc expiration-date]]]
This query is used to retrieve PFSes that have a current, non-expired
ALC attached. Pretty obvious need for an advertising site, but totally
non-portable to other stores.
> Before I go try to fix that, I wanted to make sure that no-one
> seriously disagrees.
I'm not sure it's possible. You would have to come up with a way to
express query constraints that could be implemented for all stores, some
sort of "structured query language". Then each store would need an
implementation of this common language. Even then, to permit types of
query not supported by the query language, there would need to be a
passthrough mode.
The question is, how often do webapps really want to change stores, and
are unwilling to port the custom :where-clauses they've used?
--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
