class Page(Unit):
    name = UnitProperty()

    def last_mod(cls, sandbox=None):
        if sandbox is None:
            sandbox = arena.new_sandbox()

        e = sandbox.view(Entry, ('lastModified', 'page'))
        if e:
            e.sort()
            lastmod, lastpage = e[-1]
            return sandbox.unit(cls, ID=page)
        else:
            return None
    last_mod = classmethod(last_mod)

class Entry(Unit):
    data = UnitProperty()
    page = UnitProperty(int)
    lastModified = UnitProperty(datetime.datetime)

Page.one_to_many("ID", Entry, 'page')

One of these days, we’ll add support for aggregators like MAX and MIN.. :/

for page in Page.search(sort_on=(Reversed(Page.entries.lastModified),),
                        limit=1):
    latest_page = page
    break

This fires exactly one SQL query and loads the page and all associated entries. Here’s another solution – first find the latest entry and then the associated page. This would work even if entries was a ‘lazy’ attribute:

for entry in Entry.search(sort_on=(Reversed(Entry.lastModified),), limit=1):
    latest_entry = entry
    break

latest_page = Page.find_one(entries=latest_entry)

I’m wondering why something like above would not be possible in SQLObject, or is it that an Entry may exist for classes other than Page?

run(rm.user + rm.address.where(rm.address.city == "NewBuryport"))

Without any previous definition. This returns a Query result, wrapped in a nice iterable object.

In my yet-to-be-written ORM I’d like the classes to be tied to relations (views), not relvars (tables). This allows for a more natural mapping between Objects (which often span multiple tables) and the Relational Model. The syntax might be:

class UserRecord(relation):
    """
    % user join address
    """

m = UserRecord.where("address1 = 'NewBuryport')

or (page case)

class NewestPage(relation):
"""
This is a class whose instances always contain the newest page.
% page join entry where lastModified = (entry over max(lastModified))
"""

The relation is expressed in the doc string. Of course my dream ORm has a built in Tutorial-D parser, so I can write elegant expressions and have them work. There’s no reason this couldn’t create an object that was then updateable to the original tables in question. There are a ton of other doors that open up too, like taking two random runtime instances and joining them, or inserting one “set” into another one of the same type. The idea is mostly based on Date’s work and the third manifesto.

There are a lot of issues to work out, but I think it’s an elegant way to solve the recurring query issue of ORM’s.

Were I writing a C++ or Java library, I’d know where to go for a good parser generator. But what’s the tool of choice for Python?

I think ToyParserGenerator is the most Pythonic solution. http://christophe.delord.free.fr/en/tpg/