We "define" the model in a separate package - all the classes and relationships are in there. There are database support items as well, and some of the advanced/business logic that manipulate the ORM objects. By advanced-database-specific logic, an example might be: resetting a password is a function that checks the existing password against current & past ones, updates the current credentials table, and migrates a consumed credential into a table of invalid previously used options - it's a multi-step database update.
The webapps typically have a "model" namespace, but that just invokes the 'shared' model package and contains any application/implementation specific model logic. Everything is written so it can be easily migrated into the shared model package so all of the coordinated apps/utilities can leverage it. This is just a personal preference my I have gravitated towards with my team over the past few years. We've just never built a MVC app where the model only serves a single app after a few months. There are always new tools/services/etc needed and this approach keeps everything centralized... especially many of the test suites. One "project" was originally a Pyramid app that has grown to also be a Celery Utility, Twisted Daemon with 9 services, and about 50 python tools. They all use a central SqlAlchemy model. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
