David Driver wrote:
> For the majority of objects in our db's we have a set of standard fields:
>
> tablenameKey (surrogate primary key)
> Ref (a user Id or transaction Id or something along those lines)
> Status
> Create date
> Create user
> Create application
> Update date
> Update user
> Update application
> Delete date
> Delete user
> Delete application
>
> Every major table contains these fields, sorted alphabetically amongst
> the other needed data for the table.
>
> I have been through the docs quickly and I am several pages into
> actually working through the examples and I don't see any to inherit
> this sort of behavior. Have I missed something?
well not to confuse "inheritance" with an object that is mapped against
two tables, what you want here is a collection of columns that gets added
to every Table definition. There is nothing built-in right now to support
this, but you could write a function:
for table in all_tables:
for col in standard_cols:
table.append_item(col)
>
> Also I have a question about organizing large numbers of tables. In
> the zblog example there is a file for tables, individual files for the
> classes that are actually used and a file that contains the mappers
> that also set up the get by functions in the classes that they map to.
>
> This looks like it would work for probably up to twenty tables. Does
> it make more sense to just put the class, the table and the mapper all
> in the same file, one for an entity?
it makes sense to do it the way you think it should be done. My own
philosophy is that the domain layer should be totally separate from the
persistence layer, so I would not put the table/mapper in the same file as
the class, for a large application. When I have many tables, I break up
the "mapping" layer of my application into more than one file, often
corresponding to how my domain layer is laid out. It also might be
easiest to have tables and mappers that are related to be in the same
file.
So if my application had major layers like:
users/authentication
account management
messaging
document management
I might make a directory "mappers", and a separate .py file for each of
those areas, containing the relevant tables and the mappers that attach to
the classes.
- mike
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
