Subject | RFC: Metadata extensions for FDB |
---|---|
Author | Pavel Cisar |
Post date | 2013-05-14T15:54:13Z |
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
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