Gossamer Forum
Quote Reply
Primary Key (c->pk) bug
It seems if you try to set up a primary key:

c->pk ('term1', 'term2')

When the table is created, you have the primary key entered two times.

Similarly, if you use three terms, the key is entered 3 times (for a total of 9 Primary entries).

Obvious logic bug here :)




PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] Primary Key (c->pk) bug In reply to
Hi,

We are dropping support for multiple primary keys, and in future releases this logic will be completely removed from GT::SQL. We found it added a lot of extra headaches for a case we hardly ever use. =)

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Alex] Primary Key (c->pk) bug In reply to
Well :)

That means I'm gonna have'ta rewrite the search logger pretty much from the ground up :)

The only place multiple primary keys find a use is in logging something that is incremented or modified by something else, such as daily keywords. Basically, a text-based key system. Since the 'autoincrement' function seems to be the basis of Links SQL, in keying tables, using it for something like search logging incurrs only a minor penalty, and most likely -- as you say -- will save a lot of code overhead maintennence headaches.

Essentially, all Links SQL tables should have an AutoIncrement field ID or AutoID as the first field in the table, as both a stylistic and functional process. It would allow the same functions to work on all tables, reguardless.

To this end.... you might want to add to the admin a way to list all the tables in the links database (ie: any table with the current links prefix) and allow a user to create and/or modify a .def file. It should be a simple thing to add, but it will save a lot of support headaches, especially as the number of supported plugins starts to rise.






PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.