Re: [Modeling-users] Installation tests failure (datetime) - osx, pypgsql

[Sebastien B. <sbi...@us...>]

Mario Ruggier <ma...@ru...> writes:

> However, it also makes me ask why does the XML model include the
> adaptorName and connectionDictionary attributes?  These are specifying
> mysql or postgres... so the rest of the model defn should comply? I
> know, it should be independent, but then also both these attributes
> should not appear here (in any case they make the model, as is, not
> portable).

Okay, I see what you mean, but from a practical point of view
Entity-Relationship Models are always dependent to the underlying
database (one example: the supported sql datatypes vary from on backend
to another).

However, there is one prominent reason for having connection
dictionaries within each model. Connection dictionaries act like
identifiers for databases. At runtime, when the core manages two (or
more) models it needs to know whether they are in the same database ; if
they do, both models shares the same architecture (caching, etc.), if
they don't, they won't! More precisely, that means sharing (or not
sharing) the database layer (made of Database, DatabaseContext and
DatabaseChannel) and the Adaptor Layer (made of Adaptor, AdaptorContext
and AdaptorChannel). Hence, a model needs to be, and actuall is,
strongly bound to the db's conn.dict. at runtime, therefore it is
included in the model. BTW that's not the only way to go, agreed.

> >> Evaluating: DROP TABLE WRITER
> >> Couldn't evaluate expression DROP TABLE WRITER. Reason:
> >> libpq.OperationalError:ERROR:  Cannot drop table writer because ot=
her
> >> objects depend on it
> >>          Use DROP ... CASCADE to drop the dependent objects too
> >
> > Although logical, that's amazing, I never get this with postgres
> > 7.2.1. I've to check that, and see if I can find a common
> > behaviour. If someone as any hints about this, please share!
>=20
> No ideas, but why is it logical?

Postgresql v7.3 just refuses to drop a table when referential
constraints are attached to it (except when instructed to 'cascade' the
delete --unsupported feature in v7.2). I suspect this has to do this the
fact that deleting referential constraints is a childish on 7.3 --for
7.2 see http://www.freebsddiary.org/postgresql-dropping-constraints.php
Not exactly straightforward, humm?!!

-- S=E9bastien.