I would prefer option 2: Database class that takes Connection object as constructor parameter possibly with convenience function on connection object e.g con.databasemeta() don't think publishing it as separate package is needed.
Having database metadata object would be very useful to me. On Tue, May 14, 2013 at 5:54 PM, Pavel Cisar <pci...@ibphoenix.cz> wrote: > ** > > > Hi all, > > I have "metadata" extension for FDB in development for some time now, > and I'm getting close to release it (intended for 1.2 release). The > basic idea is to provide database metadata (and other selected useful > information like common queries/operations on top of monitoring tables) > as collections of Python objects for easy access and manipulation. > However, this is huge addition to "basic" functionality mandated by > Python DB API 2.0, and it's not necessary for work with databases. So I > tend to keep it separated from core functionality. On the other hand, > this all naturally fits to Connection class, so I would appreciate some > feedback from end FDB users here. > > Right now these extensions are separated into independent submodule > fdb.utils. The main "access" point is Database class, but this module > also contains other metadata classes (tables, domains, indices etc.). > The submodule was introduced to keep indirectly used classes/code from > main FDB namespace, and import only Database class into it (or not). > > There are several arrangements I currently consider: > > 1. Database is subclass of Connection returned by > connect/create_database instead Connection on request. These functions > will have optional connection_class named parameter (defaults to > Connection) to return instance of any (either Database from fdb.utils or > user created) Connection subclass instead Connection. Other option is > addition of connect/create_database also in fdb.utils, but these > functions would return Database instead Connection, but parametrized > ones are imho better. > > The obvious advantage of this scenario is that you have both > functionalities in single object. Disadvatage is that you would get big > ball of code/attributes which you may not use very often - if at all. > > 2. Database is independent class working with Connection instance > provided on creation. This arrangement clearly separates both > functionalities. Database instance provides extended attributes and > functions only, for basic access you'll use the Connection instance, so > you may need to keep around both. On the other hand it's easier and more > effective arrangement if you don't want to use metadata functionality > extensively, as you can easily ignore it or drop the Database object any > time without disruption to core (Connection) functionality of your > application. > > 3. Hybrid case between 1. a 2. Database is independent class (like in > 2.) but works as transparent proxy to Connection provided, i.e. has > getattr that passes calls to directly unhandled names to Connection. > > Extreme cases: > > 4. Don't bother and extend Connection class directly. > > 5. Create separate (namespace?) package with this extended functionality > to keep driver package pure. Who needs such extension can easily install > it from PyPI. The connection to FDB Connection could be either 1. or 2. > method. > > My personal preference is slightly toward option 1 (maybe as 5.), but > I'm open to any suggestions. > > What is your preference? > > best regards > Pavel Cisar > IBPhoenix > > > -- Gerdus van Zyl http://about.me/gerdus
