On 4/18/07, Dan Korostelev <[EMAIL PROTECTED]> wrote: > On 4/19/07, Ben Bangert <[EMAIL PROTECTED]> wrote: > > > On Apr 18, 2007, at 12:03 PM, Mike Orr wrote: > > > Great idea. Pylons definitely needs a database administration tool. > > > My main concern is about basing it on the ORM layer rather than > > > accessing tables directly. The application I'm working on now uses > > > SQLAlchemy for its auto-retry connections and SQL builder, but I found > > > the ORM to be unnecessary complexity for it. Could AdminPylon support > > > both ORM and non-ORM interfaces? > > I believe that would add a significant amount of redundant complexity > > to this, as SA has already abstracted and done a ton of introspection > > work that would need to be done yet again. Adding stuff like this > > will bring necessary requirements on other tools, which is why its > > place is not in Pylons itself, but in additional tools, and I think > > that's just fine. ;) > > > > Ben is right, I don't want to reinvent the abstraction wheel that is already > done by SQLAlchemy.
What complexity? The job of a database admin app is to display records in tables, edit a record in a form, and link the Add and Delete buttons to some "add" and "delete" function. There's nothing intrinsically ORM or non-ORM about that, or am I missing something? If the UI code is separate from the database interaction code with an abstract interface in between, and the UI treats a record as "any object with attributes", then it's easy to swap out the database code for a different ORM, a non-ORM, or even a non-SQL database. You don't have to write any database module except the SQLAlchemy/ORM one, but I don't think it would be much more work to make the application capable of working with a different one. If there are places where it really is more convenient for the UI to know about the ORM, I'm curious what they are. > Also, working with lower level DB tables will require > developers to define table relationships in the controller, when it should > be done (and is done by SA mapper) in the model. That's the developer's problem, not yours. I stopped using relations when I found out MiddleKit did the same. I just select from one table at a time and handle the relations in Python. It means more database queries but I'd rather work in Python than complicated SQL, and it makes it easier to recover if a record is missing in one of the related tables. My model is a series of high-level business functions; the database model is private to it. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
