On Mon, Dec 26, 2011 at 7:42 PM, Ahmed <[email protected]> wrote: > So to clarify again, the function of SQLAHelper is to help me > reference my declarative base(s) (or session) via > SQLAhelper.get_base() in the library code, without a direct reference > to the app? And if so, how does this work, does it do that by looking > into the thread or what?
No, there's no magic. Magic got a bad reputation in Pylons1, CherryPy, etc. SQLAHelper defines a declarative base and a contextual session. You can use them if you want to, or define your own, but to get the sharing benefit you'll have to use its. The Akhet manual has an example of the recommended usage. http://docs.pylonsproject.org/projects/akhet/en/latest/model_examples.html Model Examples (Note: the 'akhet' *scaffold* will probably go away in the next version, but the techniques in the manual will remain.) In the normal case, you don't define a Base or Session, but instead use the ones SQLAHelper has predefined. # models.py import sqlahelper Base = sqlahelper.get_base() Session = sqlahelper.get_session() # Contextual DBSession However, if you're passing arguments to declarative_base() to customize the Base, you'll have to do it differently. You'll have to define the Base and then tell SQLAHelper to use it. This is a new feature added to SQLAHelper 1.0 so it's not shown in the Akhet manual yet. # models.py import sqlahelper import sqlalchemy.ext.declarative as declarative Session = sqlahelper.get_session() class MyDeclarativeSuperclass(object): @classmethod def query(class_): """"Return a query of the ORM subclass.""" return Session.query(class_) Base = declarative.declarative_base(cls=MyDeclarativeSuperclass) sqlahelper.set_base(Base) In this case, since you're modifying SQLAHelper's base, you'll have to execute this code before importing any modules that call get_base(). > My second question is about the use of a second engine. I looked at > SQLAHelper docs and found it supports a default engine plus additional > engines. Now I use one database but there is only one place where I > can need to look at a second database. What is the best practice here? > Do I use for the new database models the same DeclarativeBase as the > 1st database models and use the SQLAHelper bind method for these > models, or do I give them a separate Base (but how will get_base() > then work???) ? A Base has a metadata, and a metadata references tables by name. So as long as two different tables don't have the same name, you can use the same metadata for both databases, and thus the same Base. That's *can*, not *must* or *should*. I can't tell you whether it's better to use one Base for all your databases or a different one for each database; it depends on the situation. You can ask the experts on the SQLAlchemy list for advice on your specific databases. But SQLAHelper has only one Base. So if you need a second one, you'll have to define it outside SQLAHelper. The purpose of SQLAHelper is to solve the most common problem, which is sharing a single Base and Session across multiple modules, including those written by third parties who don't know about your application. But when you start getting multiple databases in the application, it may get beyond what the shared Base can provide. In that case, you can decide whether one database is general-purpose, used by several modules and third-party libraries, while another database is single-purpose, used only by one module. Then there's a clear answer: use SQLAHelper's Base for the shared database, and your own Base for the single-purpose database. For instance, the second database may be specifically for site statistics, searching, an external database you're consulting, etc. These would all be single-purpose databases, which wouldn't have to be shared. If you do have one general-purpose database and one (or more) single-purpose database(s), you'd make the general-purpose engine the default one. If you have two databases used equally widely, you can choose one arbitrarily to be the default engine, or not define a default engine at all. The engine repository is probably the least-used part of SQLAHelper. In the normal case, your Session is bound to an engine (or engines), and you can always access the engine through it, so you don't need to call get_engine(). If you bind the Base's metadata to an engine, the same thing applies. So when would you ever call get_engine()? I don't know, but it's possible that one module might want to define an engine, and another module or function might want to access it by name, rather than passing an engine object back and forth and storing it in some ad hoc place. The engine repository provides a way to do that. -- 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.
