[Fdo_dev] About RDBI's get_gen_id() function

[Dan Stoica]

Hi,

I would agree with option 1), i.e. adding 'column' as input parameter.
Although is quite unusual having more than one auto-generated columns on
a table...

Unfortunately is going to break all the generic rdbms drivers since they
implement rdbi_get_gen_id(). Not a big deal, just more work.

BTW, what happens in PostGis when passing a NULL or an empty column name
to whatever function gets the auto-generated values?

As for MySql and the logically unsafe issue: FDO does inserts table by
table and then fetches the auto-generated values right away. In a
multi-user environment the underlying RDBMS guarantees the isolation.
Therefore I don't see any risk.

Dan.



-----Original Message-----
From: fdo_dev-bounces at lists.osgeo.org
[mailto:fdo_dev-bounces at lists.osgeo.org] On Behalf Of Badreddine Karoui
Sent: Wednesday, January 10, 2007 10:14 AM
To: fdo_dev
Subject: RE: [Fdo_dev] About RDBI's get_gen_id() function

Hi,

 The GDBI/RDBI interface is not cast in stone. Option 1 seems the
reasonable solution to me. MySql driver just have to be fixed up in this
case and no need for the kludge of option 2.

Badreddine

-----Original Message-----
From: fdo_dev-bounces at lists.osgeo.org
[mailto:fdo_dev-bounces at lists.osgeo.org] On Behalf Of Mateusz Loskot
Sent: Wednesday, January 10, 2007 9:51 AM
To: fdo_dev
Subject: [Fdo_dev] About RDBI's get_gen_id() function

Hi,

Hello after holidays and Happy New Year!


I'm struggling with small problem - implementation of get_gen_id()
function in RDBI driver for PostGIS.

The problem is that the higher level - GDBI - calling get_gen_id() does
not provide me with enough details.
The prototype looks as follows:

get_gen_id(postgis_context [in], table_name [in], id [out])

For MySQL it works because LAST_INSERT_ID returns session-wide value for
current connection.

In PostgreSQL the situation is slightly different, to access particular
sequence, table name and column name are required.
Unfortunately, I don't get column name from the GDBI layer.

Unfortunately, I can't drop the GDBI usage here and nowhere in my
provider, so I have to deal with this issue in some way.

I see two solutions:

1) Change a bit the GDBI layer to provide me with column name too.
All tables and sequences for FDO meta schema are hard coded, so column
names also could be.

Then GdbiCommands::NextRDBMSAutoincrementNumber(sequence) function could
look as follows (pseudo-code):


if (sequence == HARDCODED_SEQ)
{
  table = HARDCODED_TABLE_NAME
  column = HARDCODED_COLUMN_NAME
}

get_gen_id(context, table, column, &id [out]);

Certainly, for MySQL and others, column param can be unused,
as table for MySQL is now.

I believe this change doesn't break any code on higher level, because
it's internal for GDBI and RDBI.
However, it would breat the MySQL code - additional parameter for
get_gen_id() function.


2) No GDBI changes, but I will resolve table name to column name inside
my RDBI driver. But here I'd need confirmation that there is
constant/unchangeable relation between table name and column name.

So, if I will get 'f_classdefinition' table, I can safely
assume the column name is 'classid'.


What do you think?
May be you'd suggest a better one?



BTW, I think the MySQL solution is logically unsafe.
For MySQL get_gen_id() returns session-wide version, without any
verification of table or table + column.
So, it is possible to occur, the sequence of operations will be as
follows:

1. auto-increment field X in table A
2. auto-increment field Y in table B
3. Try to fetch value of auto-increment field for X in A

and because of nature of LAST_INSERT_ID(), incorrect value will be
returned.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
Fdo_dev mailing list
Fdo_dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo_dev

_______________________________________________
Fdo_dev mailing list
Fdo_dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo_dev