> The basic idea of a persistence layer (as I understand it) is that > you attempt to isolate applications from the database to the point > that the application and the data model can vary independently > without requiring major code changes. As the paper above puts it, > a well build persistence layer for an application should allow > moving tables, renaming tables, renaming columns, and reorganizing > tables without affecting the applications that access them. > > I am not optimistic enough to think that any system is *that* good, > but it looks like someone could get quite a bit done towards that > goal using SQLAlchemy if they worked at it. > > My current list of best practices to accomplish this goal includes: > > * explicitly set column names in the data mappers to avoid > dependencies on column names > * keep all mappers and setup in one common module that you use > everywhere > * use the sql construction language for all queries > > As you can see, my list is quite short. :) > > Does anyone have additional suggestions for someone just getting > started with SQLAlchemy?
well,... Designing for the above goal may be doable, but keeping it and maintaning it may become a nightmare (i didn't say _will_). Also it depends if your DB-model will follow your App-model or vice-versa. IMO, most times it ends up as the DB is leading (as design etc) and the app is following. And fighting against it is hard. And it also depends of how much automaticity you want, and on what level. e.g. you'll have to do these: - 1) define the you app model - class hierarchy and how it decomposes/splits into DB-tables, as well as what references/ relates to what in what way; plus an idea of what queries - 2) define the translations-tables for names of columns, tables, relations - 3) build the SA model, applying 2) over 1) - 4) invent the SA queries that you need - 5) ... You can go direct SA coding by hand, or use some automation tool, at least for building the DB-model (tables & mappers). One is activemapper (which does relations but does not do inheritances). It will build your tables/mappers/relations dynamicaly, given ~declarative description, within your classes. Or try my new sawrap (which does classes but does not do many2* relations yet; next version will do basic expressions). It will build your tables/mappers/inheritances/polymorphisms/references dynamicaly, given declarative description, within your classes. It's still experimental, although we're now running our first prototype application over it (30 classes), not writing a single line of SQL (nor bothering about joins, foreign keys, whatever). If it is too dynamic and too hidden for you, at least you can use it to _generate_ the source code needed to setup your SA tables/mappers and play with it to see which is best. The sawrap's total size is small - about 1000 lines. As you want your db to be _completely_ separated from the app, u may need more layers inserted between - above tools will assume same column/table names as your attributes/classes. Although this can be easily fixed. See, i have also started looking at SA 4 months ago, because for me 10 lines SQL is 9 lines too much, while doing _all_ by hand is not possible. Then i realized that, no, it's worse, 100 lines is 99 lines too much, and even 10 munites thinking about SQL is 9 minutes too much. u see where i'm getting - and i'm leading 5 people. The point is to focus on important things and not on routine stuff. As comparative measurement, the prototype has 30 classes are about 150 lines of python src to declare what we want; as comparison the generated python source (which is, SA calls for 30 tables/ 40 mappers) is about 700 lines. have fun svil http://linuxteam.sistechnology.com/o2rm/sawrap0126.tar.bz2 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
