[Chicago] Yet another ORM for Python
carl at personnelware.com
Wed Jul 11 06:05:47 CEST 2007
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...
More information about the Chicago