Re: [gnome-db] constraints

On 10/19/06, Stian Skjelstad <stian nixia no> wrote:
> > Implementation missing: database_constraints_update_list() in
> > gda-dict-database.c line 1167
> Yes, some features are still missing... The current implementation
> uses PK and FK fields as reported by the TABLES schema query to
> maintain the list of constraints; it works but there are some
> limitations which will be removed when we use the CONSTRAINTS schema
> query.

I assume this is a something that will be done before the 2.x
release :-p

No, it's for after the 2.0 (for the 2.2 probably) as it is currently
working wuite well and I don't want to introduce big code changes now.

> >
> > And no forreign keys is visable. I want to fix the mysql provider to
> > support mysql 4.x foreign keys, but in order to implement it, I need to
> > trigger the function that reads them, and it never got hit. Just got the
> > message above.
> >
> Two solutions to make it work now:
> 1- make sure the TABLES schema query correctly reports PK and FK
> fields for MySQL 4.x
> 2- make sure the CONSTRAINTS schema query reprts them for MySQL 4.x
> and modify libgda to use that schema query instead of the TABLES
> schema query to maintain the list of constraints.

Both methods would use the same code, since they will need to parse the
output from SHOW CREATE TABLE.

Yes, in the MySQL provider that could be the same function if it makes sense.

Another question when we first are at the question about missing
features. mysql table query, should also put out the engine used. Why?
If you want to create FK, the table you refer to has to be innodb (or
other engines that supports FK). The point is, the user needs to be able
to lookup the engine used, without haveing to do manual queries.

Yes, I agree. The GDA_CONNECTION_SCHEMA_FIELDS schema query has a last
attribute named "extra" which now currently can only contain
"AUTO_INCREMENT" if the corresponding field is auto incremented. That
column is a list of comma separated extra attributes, and we could add
an attribute like "MYSQL_ENGINE=INNODB" (or other MySQL engines of
course). If you implement this in the MySQL provider, then I can
update the documentation.

> I suggest you do the first point first (as it's easier and you'll get
> an immediate result), and then if you want do the 2nd.

I would be happy to look into it. It might take some time, since I'm new
to this project, and that my time is limited.

No problem as it can be for after the 2.0!



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]