[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUe-dev] Some questions about Introspection
From: |
Jason Cater |
Subject: |
Re: [GNUe-dev] Some questions about Introspection |
Date: |
Tue, 8 Jun 2004 14:50:36 -0500 |
User-agent: |
KMail/1.6.2 |
Johannes,
On Tuesday 08 June 2004 01:38 pm, Johannes Vetter wrote:
> First I was wondering why there's a 'defaultBehavior' which is used as
> 'introspector' ... (what has behavior to do with an
> introspection-instance/class)? Having a connection instance one can
> access the proper introspection-implementation using the property
> 'introspector'.
Bear in mind that we separate the schema behavior (Introspection) from the
connection objects because it is very possible to need another datasource
driver to "behave" like another database.
There is a partially implemented attribute for the connection.conf files,
called behavior, that can set this personality.
The best example I can think of is an ODBC connection:
[myconnection]
provider=odbc
behavior=postgresql
service=MyDSN
We use the odbc connection objects, but create a
postgresql.Schema.Introspection instance to handle the introspector class.
This also applies to variants within the same database. For example, with IBM
DB/2, there was an old way and a new way to access the schema data when
introspecting. So, we could create a datasource.drivers.db2.* and a
datasource.drivers.db2-old.*, where the latter only contained introspection
support.
Also, the same thing with Oracle. The schema stuff for Oracle before 7.0 is
different than from 7.0 and forward.
> In 'datasource.drivers.<vendor>.Schema' there are two packages:
> 'Discovery' and 'Creation'. The first one holds usually a module called
> 'Introspection' with a class of the same name, derived from
> 'datasources.GIntrospection'. This class retrieves schema-information
> from the backend and is used by gnue-designer at the moment
> (SchemaNavigator and DatasourceEditor i think). But besides this
> intuitive functions there's also a 'write ()' method in
> GIntrospection.Introspection ?! As one could tend to think this is the
> purpose of 'Schema.Creation' this a bit confusing.
The .write() method needs to be deleted. That was accidentally cut-and-pasted
during the conversion process when we created the new directory structure.
We don't have a good API for writing schemas yet, so I'm definitely open. I
could imagine it working a lot like the Introspection classes as far as what
gets passed to __init__().
One thing I imagined would happen eventually is that the current gnue-schema
classes would be moved into this directory structure. They need to be
accessible without creating any connection to the database.
> On the other hand I'm wondering how to implement a schema-creation
> functionality if not integrated into the same class as the
> introspection. Maybe this should be given an other name, e.g.
> 'SchemaSupport', which handles both aspects retrieval and creation? As I
> see things we could remove on abstraction layer, namely the
> Discovery/Creation layer. I'd replace it by something like
> 'Schema.support' or 'Schema.Introspection' and 'Schema.Creation' (if one
> whish to keep them apart).
I don't see how the Introspection and Creation are related as far as
implementation or shared code goes.
-- Jason