> > I think it would be interesting to create some of those plugins > > towards the RUM data abstraction layer, but I don't at all think it's > > necessary for most pluggable apps -- a very large majority of our > > users are going to be using SQLAlchemy. And if they aren't we can > > still use SA in plugins and have the transaction manager manage the > > interactions between the plugin database commits and the ones that the > > app does itself. > > I didn't realise SA could do that, but that might go a long way to > solving the problem. > > SA is great, as 99% agree, but if we start assuming it for the > TG/Pylons app ecosystem, we could very quickly end up like Django - > all that functionality lost unless you use a particular stack (in the > case SA).
I made my own rumish thing ( much more primitive, no introspection ), and to tell you the truth, I think eliminating SA dependency is not hard. SA and storm and dejavu are well designed so that you can pretty much write an interface in one page of code to do you updates and selects that would be fine in 90% of use cases. If you limit your use to: - get by id - get by dictionary - list, one with exception, one with none - update by dictionary You just don't really need to call the orm interface in your rest-admin-controller. I don't think it would be at all hard to add an adapter to allow the app to work with dejavu, storm, so, etc. So, yeah, I agree with mark, the extra complexity of adding that abstraction layer is absolutely and utterly worth it. Iain --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
