On 6/20/07, Ben Bangert <[EMAIL PROTECTED]> wrote: > I didn't see anything about who was working on a SAContext or its > progress, which was the main motivation for me to start adding more > methods into Pylons to handle loading configs well. Let me know the > scope of what SAContext will cover so I can avoid any replication of > work.
http://groups.google.com/group/pylons-discuss/browse_thread/thread/90abf0582c1248c3/3cc1091d23d3f05f?lnk=gst&q=SAContext&rnum=2#3cc1091d23d3f05f Michael and I have agreed on an implementation design so I just have to implement it. He's busy with other tickets and documentation right now. I'm planning to use Michael's API but change the constructor a bit to handle multiple databases in the config file. We need a generic config function that returns all config vars under a certain prefix as a dict. Both SAContext and my Buffet replacement need that. def get_options(options_dict, prefix, strip_prefix=True): # options_dict is app_conf. prefix += "." ret = {} for key in options_dict.iterkeys(): if key.startswith(prefix): newkey = key[prefix:] ret[newkey] = options_dict[key] return ret I'm not quite sure how to handle the subkey (the middle part of "sqlalchemy.myengine.dburi"). On the one hand we could parse only a certain specified subkey. On the other hand we could set up engines for all subkeys found in one step, which would require either a function that lists the subkeys, or one that returns a two-level dict of subkey : option : value. This is why going to mandatory subkeys for "sqlalchemy.default.dburi" is appealing: it avoids having to write two sets of code for whether the subkey is present. I'm also thinking about making a logging initializer that would work similarly: "logging.realm.subrealm.level = info", something like that. Another thing that's necessary is a standard way to preconvert into and boolean values. asbool works but there's no asint, and int() is exception-prone. I favor preconverting values and setting defaults at the beginning of the application, because if the conversion is buried in every function that reads a config value, you'll get exceptions happening at obscure times. Better to have all exceptions occur at startup as much as possible. I was thinking of something like this: def convert_options(app_conf, bool_options=['echo', 'echo_pool'], int_options=['pool_recycle']): # Modify app_conf in place. This gets problematic for setting defaults and ignoring prefixes though. Maybe a one-liner for each option: convert_option(app_conf, option_name, converter, default=NoDefault, prefix=None): # Convert option in place or raise exception. # Converter is a function like int or bool (which can be a signal to use asbool instead) # Exception if option is missing and NoDefault. # If prefix is "sqlalchemy" and option_name is "pool_recycle", operate on all options # with that prefix and suffix regardless of subkey. If you can work on optiion-parsing functions, I'll work on the rest. I actually think these option-parsing functions belong in paste.deploy because they're useful in all applications, but first they have to stabilize. > The 'g' thing is gone already in trunk. Having it fixed at the > metadata also means you can use autoload=True I assume? Right now one > needs to import create_engine and connect it before a table statement > including autoload can even exist (which kind of sucks). Or use session_context.current.bind_to to get the engine, which sucks almost as badly. Then users wonder if the engine is thread safe (it is) because they define their tables at the global scope but use them in various other threads. The idea is to pair every engine with a BoundMetaData so they act as a unit. The SAContext acts as a container for engine-metadata pairs, with one being the default. sac.session will be a property for the current session, using a private SessionContext. sac.query will (maybe?) be a shortcut for sac.session.query. This should cover almost all user applications, including those that do weird things like a transaction spanning multiple databases. -- 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 -~----------~----~----~----~------~----~------~--~---
