Although I think queries are very important, I think andi's ref
collections (and soon sets) can better address many of the problems
you'd typically use a more traditional query for. They can make it
really easy to "hook up" new parcel pieces to existing pieces of
chandler, something that's awkward or slow to do with queries. There are
relatively efficient, scale well, can persist result sets, keep track of
ordered lists and provide notifications about changes to the UI. It's
important to understand all the tools at our disposal and use the right
tool for the task, rather than depending upon on a single tool, e.g. a
traditional query.
John
Phillip J. Eby wrote:
At 08:55 AM 6/25/2005 -0700, Andi Vajda wrote:
So, the Kind method would only be useful in situations when you
already have a kind object -- and I'll be trying to eliminate those
situations as much as possible. :)
Anytime you have an Item object, you have its Kind object, so I'm a
little confused by what you're saying here.
In the Chandler code base, kind queries were being used where there
was *no* item or kind available, only a view. So code was doing
either SomeClass.getKind(view) and kind-querying that, or else doing
view.findPath() to look up the kind.
Instead of looking for all items of Kind Web.Server, you could have
all such items sit in a 'servers' attribute (a ref collection) of
another item such as a Web.Servers item which is responsible for
starting or managing all such
servers. That Web.Servers item would itself be looked up via a well
known path - not a parent/child path but a ref collection based path
for example.
That adds complexity to the API exposed to parcel developers;
currently a developer can simply create the item, without needing to
link it to some other object. It also means the OSAF developer
creating an extension point needs to set up and document these "well
known" paths.
More than an efficiency issue, there also is a paradigm issue here.
The Chandler repository is not like a relational database where you
use some fancy query to find exactly what you want.
Key phrase: "exactly what you want". :) As far as I can tell, a kind
query is indeed exactly what the developers who used them wanted, at
virtually all of the places I found them.
In Chandler's case, the repository is being used as a single-user
database for a single application; this means that for many object
types, the natural working set is the entire class extent. For
example, one does not need to have POPAccount instances that are *not*
used by the Accounts dialog. In fact, it would be a bug to have such
a thing.
It is more like an object database, that is, a persistent graph of
objects which the application navigates. That graph has well known
entry points: roots or well known paths remaining to be spec'ed when
solving the 'Addressing' issue.
You're describing a hierarchical or network database, or a simple
object store; object *databases* generally support intensional sets
and querying against class extents without any requirement to reify
queries as navigation. Indeed, relational databases mostly replaced
hierarchical and network databases because they don't require
programmers to design and manage their own navigation structures.
Defining these well known entry points means to:
- define an addressing scheme (ref collection based paths is my
proposal)
- define a schema that contains all these commonly used collections
(all
web servers as per your example above)
Currently, the Chandler application schema is in flux, the
ItemCollection/Query stuff is being redone and the 'addressing' issue
is not settled. Once it is, we can define well known addresses to
repository entry points containing collections of items of interest.
Until then, using KindQuery is the usual starting point but I do hope
that once these issues are fixed, we use it only as last resort.
I don't see any actual conflict here; what stops you from simply
maintaining kind-extent sets internally as part of this new addressing
paradigm? Do you intend not to support intentional sets at all, only
extensional ones? Because if so, I think that's going in a bad
direction for developer comprehension and usability. This is one of
ZODB's bigger flaws: it has no inherent mechanism for efficient
queries, but you instead have to reify sets as navigation extents,
such as via ZCatalog.
Currently, parcel definition is quite simple because for many kinds of
things, you can simply toss an item in the bucket and have it work,
without needing to know about anything else. It's sufficient to
create a web server item or wakeup caller item (or RSS feed, or any
number of other things we haven't invented yet), and it "just works".
I'd hate to throw away that feature just so we can make the repository
into a less generally-useful database.
Anyway, all database paradigm discussion aside, my main point is that
iterItems() is an easy and obvious way to provide extension points for
the Chandler platform, that are easy for parcel developers to extend
by simply creating items and having them be automatically discovered.
I'd prefer not to have the feature go away and then be forced to
simulate it at the schema layer, e.g. by creating an 'extent' biref
from Kinds to their Items and making schema.Item.__init__ add all
items to the extent. This just seems like busywork to me, as well as
duplicating the half-biref that already exists from items to their kinds.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
