[Chicago] Yet another ORM for Python

[Brantley Harris]

On 7/10/07, Carl Karsten <carl at personnelware.com> wrote:
> Here is how I deal with changes during development: DROP DATABASE.  see below
> for how easy it can be.

Ooh, nifty thanks!

> Now from some blasphemy: I miss the level nuttiness that the VFP frameworks have
> hit.  the one I used had about 150 'attributes' that could be assigned to most
> things db related: the whole db, a table, a field in a view, a SP, etc.  Things
> like Data type, size, "Caption" default, (django has that, just relating) short
> caption, long caption, validation, FK Lookups that include what fields to
> display, additional fields to pull on selection, SQL fragments to use when the
> field is (not null, not empty) help text, help context ID.  There was enough
> that they ended up being stored in db tables - both the settings and
> descriptions/attribute names.  which meant the whole thing had a nifty UI. OTHO,
> much of that doesn't apply to a browser, unless you want to start doing web2.0
> stuff.   for now, I am ok with web 1.2

Yeah, I was thinking about this a while ago, if you could represent
your models as database objects themselves, in a nice UI, then schema
evolution is a snap, as the UI can track everything you do.  But it
takes it away from the code, which is where I like it.  On the other
hand, if you could do something like this:

class Entry(modelmaker.model):
    def __str__(self):
        return self.name

And then define the actual fields for Entry in a UI, that might work...