On Jul 4, 2008, at 2:42 AM, sathya wrote:
> hello michael,
> AFAIK with STORM you can create a composite class using References
> and have class attributes point to different tables. So mapping to
> multiple tables is not a problem.
This is obviously the most basic function of any ORM. The classical
SQLAlchemy bidirectional one-to-many/many-to-one looks like:
parent = Table('parent', metadata,
Column('id', Integer, primary_key=True),
Column('data', String(50))
)
child = Table('child', metadata,
Column('id', Integer, primary_key=True),
Column('data', String(50)),
Column('parent_id', Integer, ForeignKey('parent.id'))
)
class Parent(object):
pass
class Child(object):
pass
mapper(Parent, parent, properties={
'children':relation(Child, backref='parent')
})
mapper(Child, child)
so Parent.children and Child.parent are both accessible. The loading
strategy of each (lazy, joined-table eager, dynamic) can be configured
as well.
A catalog illustrating the basic relation types are here:
http://www.sqlalchemy.org/docs/05/mappers.html#advdatamapping_relation_patterns> Here is my current state of understanding wrt SQLAlchemy and pre-
> existing DB schema's
> SQLAlchemy wants to generate schema for python classes and impose a
> certain table structure.
This is not just entirely untrue, this is the direct opposite of
SQLA's stated philosophies (stated on the homepage of the site,
throughout the docs, the mailing list, the Pypi page, blog entries of
all kinds, published books, etc. etc.).
You might be confusing us with a different project called Elixir,
which uses SQLA as its base and does make some decisions regarding
table structure. SQLA does not "generate schemas" in any case; while
the SQLA Table construct is capable of issuing DDL corresponding to
its exact user-specified design, SQLA never dictates schema design,
naming, or anything else, in any way. Many users of SQLA use it
specifically with existing databases using "metadata reflection",
which loads an existing database schema into a Python application by
reading the database's catalog tables; mappings can then be created
directly from those constructs (reflection is described here:
http://www.sqlalchemy.org/docs/05/metadata.html#metadata_tables_reflecting)
. The ORM is additionally capable of mapping and relating to
customized joins, selects, and views in order to better suit unusual
schemas (map to a select:
http://www.sqlalchemy.org/docs/05/mappers.html#advdatamapping_mapper_selects
relate on a custom join:
http://www.sqlalchemy.org/docs/05/mappers.html#advdatamapping_relation_customjoin
).
The current state of SQLA's ORM can be best understood through the
latest tutorial for the 0.5 series:
http://www.sqlalchemy.org/docs/05/ormtutorial.html
. 0.5 will have its first non-beta release most likely in August.
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at
http://www.sourceforge.net/community/cca08_______________________________________________
Plone-Users mailing list
Plone-Users@...
https://lists.sourceforge.net/lists/listinfo/plone-users
