[sqlalchemy] Re: Persistence Layer best practices with SQLAlchemy
On 1/26/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jan 25, 7:28 pm, Allen [EMAIL PROTECTED] wrote: 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. yeahto be honest, one thing that makes SA unique from most other ORMs ive seen is that its specifically *not* trying to accomplish that. as you said, youre not so optimistic about it either. my experience is that those who argue about the object-relational impedance mismatch, for which you can find endless blog/academic articles about, seem to be obsessed with a completely clean separation of objects and database. and that implies that theyd like their application to scurry along doing everything it does without nary a shadow of a relational concept being revealedso...why use a database at all then ? I agree that a complete separation is probably either a) impossible or b) going to lead to code that is so complex and difficult to maintain that it removes any advantage gained. I think there may be a happy medium somewhere in the middle though and I am hopeful that SA can help out there. I think the object and data model need to be fairly close, but I would hope that the software could allow for small variations so both the data model and the object model can be refactored and improved. For example with the ability of SA to map attributes names to columns that are named differently allows some of this. It also appears that being able to map a class to a joined relationship could allow for some very interesting capabilities as well. What I am looking for is guidance about how people use SA to try to reach this middle ground or references to any modules/plugins/extensions that could assist in this regard. I would rather not attempt to recreate the wheel so to speak and I am sure that other people out there have already created better wheels then I could dream to. :) SA's goal is absolutely not to create a programming paradigm or framework which allows pure separation of application/persistence concerns...such a framework could certainly build on top of SA, but within SA we are providing more primitive operations than that. The goal of SA is strictly to provide a rich framework for issuing SQL statements to a database. the ORM part of it, which is totally optional, then takes a straightforward approach to mapping Python classes to database tables and other selectables, and provides maybe the *beginning* of an abstractional layer, but thats about it. it assumes Python is a flexible enough language that its up to the larger framework to figure out where to hide the session.query() calls, if thats whats desired. Agreed. Python does allow a degree of flexibility that makes a pure separation less needed. As a side note, I am trying to see where ActiveMapper would fit into all of this. At first I thought that ActiveMapper would actually tie the classes closer to the data model, but after looking at it further I am starting to think that it still has all the power and flexibility of the other methods of using SA but simple encapsulates the Table and Mapper creation in a single unit. Can anyone tell me if this is a correct assessment? personally I dont really believe in a pure abstractional layer and i think the more time one spends being obsessed with it, the less one ends up getting done. lump it in there with all those other silver bullets. Agreed. The pursuit of silver bullets is a fools errand. I just hope to avoid taking the bullet and is SA and shooting myself in the foot because of lack of understanding. :) Thank you for your comments. -Allen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Persistence Layer best practices with SQLAlchemy
On 1/27/07, Allen Bierbaum [EMAIL PROTECTED] wrote: I agree that a complete separation is probably either a) impossible or b) going to lead to code that is so complex and difficult to maintain that it removes any advantage gained. I modify the schema and code in step during development, once the project is finished and enters into maintanence, the object model stays pretty much fixed. From your initial message, I'm sure whether you wanted to use raw SQL or SA's interface. The latter isolates changes much better than the former, so the rest assumes that's what you're using. Table name changes are pretty simple, change the first argument to Table and all the ForeignKeys that reference it. Field name changes are less obvious. I make use of the key= argument of the Column class because that means my queries don't need to be rewritten. Flexibility beyond that is dependent on how many queries you have scattered around your code. For code that's just using the final mapped objects, you can map pretty much anything you can query onto a particular attribute. I've done a few mapping changes where a field is normalized or de-normalized and the object stays the same. The code using the objects doesn't have to change, but the queries that touch that field generally do. Certain changes are simpler than others, your mileage may vary. I am starting to think that it still has all the power and flexibility of the other methods of using SA but simple encapsulates the Table and Mapper creation in a single unit. Can anyone tell me if this is a correct assessment? ActiveMapper implements the active record pattern while the standard SA ORM interface implements the data mapper pattern (see Fowler's Patterns of Enterprise Architecture for explanations). For basic usage, ActiveMapper is more convenient and is basically a thin wrapper over the standard. The problem is that it's relations are less powerful -- there's no primaryjoin or secondaryjoin, this is an implementation limit and can be fixed -- and quite a few of the features listed in the Advanced Datamapping section of the docs are unavailable to you. You cannot, for example, map multiple tables onto a single object, this is a design limit. You can mix and match ActiveMapper and normal SA mapped objects and definitions, but I prefer to just use active_mapper exclusively. The biggest disadvantage is that the code is spread into three locations. I work around this using code folds in Vim, but it's still a bit clunky. There is another active record mapper called TurboEntity (no ties to TurboGears despite the name), which a number of people on the TG mailing list like. The authors of ActiveMapper and TurboEntity are collaborating on a joint project to replace both with a mapper that implements a DSL which, to me, looks like a mix between Rails' ActiveRecord and Smalltalk. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Persistence Layer best practices with SQLAlchemy
On Jan 27, 2007, at 11:57 AM, Allen Bierbaum wrote: As a side note, I am trying to see where ActiveMapper would fit into all of this. At first I thought that ActiveMapper would actually tie the classes closer to the data model, but after looking at it further I am starting to think that it still has all the power and flexibility of the other methods of using SA but simple encapsulates the Table and Mapper creation in a single unit. Can anyone tell me if this is a correct assessment? there is a project going on involving ActiveMapper and TurboEntity combining to make the next generation of declarative layer. the current ActiveMapper is quite minimal. i think its getting time for them to talk about it a little bit. personally I think ActiveMapper complicates things and also requires that the entire SA api be rewritten, as most ActiveMapper issues refer to SA features that are not available through its interface. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Persistence Layer best practices with SQLAlchemy
Mike, On a side note, do u have any ideas about supporting stored procedures in some way? Be it just knowing about them and maybe calling them, or on the other end, generating them? IMO they are _some_ way to hide some of those session.queries... Although i'm just extrapolating my own vision of what sql-server is. Last week i saw a huge application wholly working on an SQl-server, sending dialog-templates and what not to the thin-gui-only-client; _all_ written in stored procs. And i immediately ran away from it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
