I hate to be posting this without an awesome solution, but I'd like someone to convince me that this is actually a good idea. I have not yet heard of a good use-case other than laziness or poor design for using SQLAHelper, and those are not qualities a library author should have. Any library that utilizes a shared global is just asking for problems when two independent packages want to use that library. If you ask each library to register their own session via some key then we're back to a little bit of sanity but then I fail to see the benefit of using a third-party package to store your Base/Session via a key versus simply having those packages depend on your own common package.
If SQLAHelper is something for people to use in their apps of their own accord with the knowledge that they may be buying into shared globals and reduced flexibility, then fine. But I don't see this as something that library authors should be using in its current form. Again, please convince me otherwise. Just as one possibility, let me throw out there the idea of a library that handles user registration. This library might want to depend on sqlalchemy rather than some abstract data store. Fine. So it defines a User, Group, Permission, and the respective link tables. It requires a metadata object to tie them together. Now some user of the library wants to use this in two different projects, ProjectA and ProjectB, but connected to different databases (the projects are unrelated). So ProjectA would use the User object with DatabaseA via SessionA, and ProjectB would use the User class with DatabaseB via SessionB. How can I do this with SQLAHelper? Without it I would expect the library to dynamically define the User class based on a Base and Session that I supply to it, it would then return me the new User class using that Base.metadata, and I could track that User class within my app. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
