[Chicago] Yet another ORM for Python

[Carl Karsten]

Brantley Harris wrote:
> 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. 

meh - lists of this=that is more config than code.  even
contact = models.ForeignKey(User,
is just a config.  There isn't any algorithm being implemented.

OTOH, it does let you put code code 'right there', like def full_name: return 
first + last.

 > 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...

I don't get the code, but the text sounds right...

Carl K