On May 9, 2007, at 8:27 AM, Antipin Aleksei wrote:
>
> Hi
>
> I'm studying examples of using database in pylons. SQLAlchemy is most
> commonly used here. But I don't understand why most of them use
> explicit
> column declaration.
> I want to use Postgres database which supports ALTER table statement.
> Following those examples if I need to change column name from
> character(30) to charcater(50) I will have to do it in my code and
> then
> in pgadmin tool. I would prefer to do it in pgadmin only and my model
> applying those changes automatically.
obviously features like reflection are provided so you dont have to
deal with that kind of stuff. however, such a feature doesnt apply
to every scenario. if an application is being developed where the
database schema is not generated by the application, and particularly
where the database is managed by a DBA down the hallway, id much
prefer the contract between my application and the actual database to
be explicit.
>
> I'm trying to get Elixir's reflection working:
>
> #models/user.py
> import pyoner.models as model
> class User(Entity):
> Entity.table = model.table_user
>
> #models/__init__.py
> from pylons.database import session_context
> from elixir import metadata
> from sqlalchemy import Table, BoundMetaData
> engine = session_context.current.bind_to
>
> table_user = Table('user', BoundMetaData(engine), autoload = True)
>
> Here I have simple table with id, username, password. It seems that
> reflection works, but User.select() ends up with:
> *<class 'sqlalchemy.exceptions.SQLError'>: (ProgrammingError) relation
> "pyoner_models_user_user" does not exist 'SELECT
> pyoner_models_user_user.id AS pyoner_models_user_user_id \nFROM
> pyoner_models_user_user ORDER BY pyoner_models_user_user.id' {}*
>
>
> I use sqlalchemy 0.3.7, elixir 0.3, pylons o.9.6
>
>
> And maybe one could provide some arguments why I should explicitly
> declare tables in my models? Some pros and cons list?
well Elixir is specifically "declarative", where an application lays
out all the properties it would like its classes to have, and those
properties in turn map to schema entities...so reflection of the
table would be the opposite of that....you are "declaring" much less.
When you use reflection and then generate the class attributes from
that reflected table, youre having the database schema drive not only
your Table metadata, but the exact specification of your domain
model. Which is not a bad thing...but in any application beyond the
most basic, its typical that a domain model and a database schema are
divergent entities. so at that stage things are easier to manage
when the structure and behavior of classes is explicitly stated
independently of table schema.
additionally its just basic decoupling of concerns that leads to SA's
default approach of tables and classes being separate. a lot of
people dont want their classes to have any awareness that they are
part of a certain hierarchy thats tied to persistence, or even to
have any awareness of their own persistence (like me).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
