[Chicago] Yet another ORM for Python

[Jason Rexilius]

Although my approach isn't great (and truth be told I usually am coding 
in PHP or perl) I use code generation scripts that read the schema and 
create the record classes, which I then manually tweak as needed.

I find that it minimizes the amount of code changes that I have to do to 
  deal with schema alterations while not injecting serious performance 
problems and still allowing custom handling as needed.




Carl Karsten wrote:
> Brantley Harris wrote:
>> That's the bit that's harsh: "we don't have a good method to apply
>> changes to the database when you change your code".  If this could be
>> solved, it would be another step towards decoupling the DBMS from the
>> general development experience, something I would love, personally.
> 
> I would love it too, but I have come to believe it is more trouble than it is 
> worth.   The only time I would use it is for upgrading a live system, and even 
> then I am skeptical exactly how much I would trust such a tool.    given that 
> there are 'lots' of "schema diff" tools that can generate a script of ALTER 
> commands, which then I can look over, I don't see much need for my development 
> environment to need it.
> 
> Here is how I deal with changes during development: DROP DATABASE.  see below 
> for how easy it can be.
> 
>> It seems to me that a good step forward for the Django ORM would be to
>> rebase itself on SQLAlchemy (which I thought was in development?)
> 
> It is, no clue how active, other than not dead yet.
> 
> 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
> 
> Carl K
> 
> 
> #!/usr/bin/env python
> # mkdbuser.py
> # prints the CREATE DATABASE and GRANT commands based on the local settings.py
> # ./mkdbuser.py | mysql -u root -p
> 
> 
> # nifty trick to get ../settings
> import os, sys
> os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
> BASE_DIR = os.path.dirname(os.path.abspath(__file__))
> apppath=os.path.abspath(BASE_DIR+'/../')
> sys.path.insert(0, apppath )
> import settings
> 
> SQL = """
> DROP DATABASE IF EXISTS %(db)s;
> CREATE DATABASE %(db)s;
> GRANT ALL
>      ON %(db)s.*
>      TO %(user)s
>      IDENTIFIED BY '%(pw)s'
>      with grant option;
> 
> """
> 
> print SQL % {
>      'db':settings.DATABASE_NAME,
>      'user':settings.DATABASE_USER,
>      'pw':settings.DATABASE_PASSWORD }
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago