Hi Jorge, On 5/4/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: > SQLAlchemy has what is call a data Mapper > http://www.martinfowler.com/eaaCatalog/dataMapper.html , > that is you define your Objects, your "tables" and the definitions that link > each other > > On the other hand > > SQLObject uses what I call a DeclarativeMapper, that is Objects that define > links which define tables. > As we all know both approach have their pros and cons but that is subject to > somewhere later.
SQLObject actually uses what Fowler calls Active Record: http://www.martinfowler.com/eaaCatalog/activeRecord.html > > Now lets think of our ORM as a MVC. One way to see it is > > The Model is our database + python bindings + SQL queries > The view is either our DataMapper(objects and links) or our > DeclarativeMapper(objects and links) note they are both the same components > just they are arrange diferent. > and The Controller which is the engine which transforms our view into model > and viceversa. > > So my proposal will be either > > 1. to implement both views in both ORM, which in theory will make migration > between each other a matter of moving data from one table to the other one > 2. To implement a DataMapper on top of SQLObject AND implement a > DeclarativeMapper on top of SQLAlchemy > > Please note in case #2 there will be > a bigger overhead, so using the "original" mapper for each ORM will be the > most efficient thing to do. Actually, implementing an Active Record layer on SQLAlchemy shouldn't be perceptibly more overhead -- your single active record layer just creates the table layer behind the scenes. My view has been that the Data Mapper pattern is a superset of the Active Record pattern. I don't know how you'd make SQLObject act like a Data Mapper, because the code has no notion of tables as separate entities from mappings. Building on Jonathan's work with ActiveMapper for SQLAlchemy, I have figured that it would be possible to extend that to implement actual compatibility with a large portion of the SQLObject API. This would provide a migration path for people using SQLObject today: you'd have SQLAlchemy objects running behind the scenes and you gradually migrate your code to using native SQLAlchemy (or ActiveMapper) patterns along the way. Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
