Karl Guertin wrote: >> 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? > > 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.
With ActiveMapper, Karl's assessment is absolutely correct. I think that some of this can be overcome by having a more actively developed and supported declarative layer. Right now, I would say that unless you have a simple enough data model to be handled by 100% ActiveMapper, you would be better off just going with the standard way of doing things. I am highly unlikely to make any enhancements to ActiveMapper, as my efforts are focused elsewhere. Now, there are a lot of cases where you really only _need_ a simple data model, and the Active Record pattern holds up very well in those cases, and its those cases that were originally targetted by ActiveMapper. But the approach that I took was naive and I really didn't have the time or help to tackle any of the issues that remain with ActiveMapper (of which there are many). Karl also wrote: > 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. and Mike chimed in with: > 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. Yes, there are three of us working on this, and we are getting closer by the minute. We have made a checklist of things that remain to be done, and one of them is documentation, which I think is absolutely a must before we release. I think we can have this done relatively quickly, but I am tied up a bit preparing for my talk at PyCon, so I am relying a bit on the other two contributors. Still, it won't be that long until we have something out as a "beta" to gather comments. Mike also said: > 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. I think ActiveMapper definitely complicates things once you start hitting its limitations. For many problems, this happens quite fast, partly because ActiveMapper is such a thin layer. That being said, I think we can do a lot better with the new approach that we are taking, and support more and more complex scenarios without truly rewriting all of SQLAlchemy's APIs. However, I think that we will likely make it clear in the documentation for our upcoming release that we will not be attempting to shoehorn a solution to every single database mapping problem into an Active Record pattern. In those situations, we will likely encourage people to go with a more traditional SQLAlchemy approach. Thats what I like so much about SQLAlchemy: by taking a more pragmatic approach to the problem it can handle nearly every database model that you throw at it. Still, you can solve many many problems with an Active Record pattern, as the plethora of Ruby on Rails applications out there prove. There is a need for a simple way to solve simple cases, and thats the sweet spot I intend to hit. I hope to see you all at PyCon! -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
