[Schevo-devel] iterators

[Patrick K. O'Brien]

Matthew Scott wrote:
> I just updated the API reference (formerly the schema reference) to
> include information on what does and does not have iterators:
> 
> http://schevo.org/reference-api.html#iterators
> 
> Here are the changes I think we should make:
> 
> - Entity sys namespaces -- these have an iterator, but should not.

I agree that this should not.

> - Query instances -- these do not have an iterator, but perhaps should
> have one that is a generator version of their __call__ method.  An
> alternative would be to make __call__ always return a generator, and
> make __iter__ an alias for it.  Yet another alternative would be to
> not have a __call__ method on a query instance, and just list(q) if
> you need a list of query results.

There are really two things here - the query, and the results (what you
get after you "execute" the query).  You *should* be able to iterate
over the results.  I'm *not* sure it makes sense to iterate over the
query itself, but I think not.  So, how to get the results in the form
of a generator?  Perhaps a call to a query should return an object (some
kind of collection that was similar to an Extent, perhaps) that was an
iterator?  It should probably be a collection of views.  But I think we
need to experiment with this some more to be sure.

> - f namespaces -- these do not have an iterator, but probably should. 
> To be consistent with q, t, and v namespaces, iterating over an f
> namespace would result in the names of fields, ordered by the order in
> which they are defined.

We must not be doing too much with these now...

> - db -- if we add __iter__ to this, it should probably iterate over
> db.extents(), ordered by extent name.
> 
> This would leave the following objects without iterators:
> 
> - db  (perhaps)

I'd feel okay calling YAGNI on this one - I don't necessarily think
iterating over extents is the only intuitively expected option here.

> - Entity instances
> 
> - Transaction instances
> 
> - View instances

Can't see these needing iterators, especially since their field
namespaces *would* have iterators already.

> Another potential change, which would have wider-reaching implications
> than those suggested above, would be to change the way q, v, t, and
> eventually f, namespace iterators act, to return the actual object
> instead of the name of the object.  This would necessitate a common
> API between the return values, such that the name of the object could
> be easily gleaned.

I somewhat agree that returning the object seems more in keeping with
the rest of Python.  At least with the f namespace.  On the other hand,
a Schevo namespace is a lot like a Python dict and with a dict the
default iterator operates on the keys, not the values of the dict.  That
would seem to support the way things are now.

> For instance, if c == db.Person.t.create, then you can't easily get a
> string 'create' from it.  We'll need to make sure that we could rely
> on, in this example, c.name == 'create'.  Partially for compatibility
> with the current Qt3-based navigator, partially because it can be
> useful to pass around a name of a method rather than a strong link to
> the method itself.
> 
> Comments?

The way a namespace works now *is* functional:

>>> for name in app.db.Configuration.t:
...     print '%r :: %r' % (name, app.db.Configuration.t[name])
...
'create' :: <bound method EntityMeta.t_create of <class
'schevo-db-schema-1.Configuration'>>
>>>

Whether that is the best way to deal with our namespaces is open to
discussion, but I think one can do everything they want with the way
they are now.  Requiring a common 'name' attr on all namespace-owned
objects (many of which are methods, custom defined in a schema) might be
more trouble than it is worth.

-- 
Patrick K. O'Brien
Orbtech       http://www.orbtech.com
Schevo        http://www.schevo.org