Re: [GNUe-dev] Some questions about Introspection

[Jason Cater]

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