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. > > yeah....to 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 revealed....so...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 -~----------~----~----~----~------~----~------~--~---
