Subject | RE: [IB-Architect] Best way to determine field precision? |
---|---|
Author | David Schnepper |
Post date | 2002-05-15T05:13:59Z |
I'm really quite glad to hear of this Python module - I've
recently started using Python a lot and had half-a-mind to
start an IB module.
To answer your specific questions.
1) Of course it's "possible" - after all the Engine does it.
Is it possible short of emulating the engine? - no.
Your solution of passing new information in the XSQLDVAR
structure is the right one, but, of course, that means
XSQLDA becomes XSQLDA2, 2 formats to support (or 3 if
"old" SQLDA hasn't gone away yet). Client vs server
mismatch fixups, etc. In other words, a fairly messy
project.
2) I wouldn't worry about the cache being invalidated.
Interbase itself caches lots of metadata info that
becomes invalid with dynamic DDL updates. The idea
of dynamic DDL is it's rare -- occurs a lot during
development, but only rarely in a production db.
And even then, hopefully when the system is down
for an upgrade.
2b) I suspect you're doing individual queries to access
the pieces of information. I suggest you compose
a join and that should get some performance improvements.
As a starting point, look at how isql does extract
of precision information.
Dave
-----Original Message-----
From: woodsplitter.rm [mailto:woodsplitter@...]
Sent: Tuesday, May 14, 2002 4:10 PM
To: IB-Architect@yahoogroups.com
Subject: [IB-Architect] Best way to determine field precision?
I'm maintaining and enhancing an Interbase/Firebird driver for
Python ( http://kinterbasdb.sourceforge.net ). Python's standard
database API requires that the driver return the precision of SELECTed
fields. I'm talking about *precision* here, not *scale* (which is
already provided by the IB API as XSQLVAR.sqlscale). For example, in
a NUMERIC(18,2) field, precision is 18.
It's obvious that, given the relation name and field name of a
SELECTed field, one can determine its precision by querying the system
tables, but there are two problems with this approach:
1. The relation name and field name of a SELECTed field are not always
provided by the IB API, as in the case of a dynamically computed field
(e.g., "SELECT x/2 FROM SOME_TABLE").
Is there *any* way to programmatically determine the field's
precision in this case?
2. Performance is terrible.
In the worst case, one must query not just one or two system tables,
but several, first to determine whether XSQLVAR.relname refers to a
table, stored procedure, or view; then to retrieve the "internal name"
of the field in question (e.g., RDB$744); finally to retrieve the
field's precision from RDB$FIELDS.
Because of the requirements of the Python DB API 2.0, this process
must be performed for every field of every SELECT query when the query
is executed. It would be possible to cache the results, except that
the field's precision might in theory be ALTERed, invalidating the
cache.
So, is it possible to determine a SELECTed field's precision in
*every* case, and can it be done with decent performance? Ideally,
the API would provide XSQLVAR.sqlprecision along with
XSQLVAR.sqlscale.
Thanks.
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
recently started using Python a lot and had half-a-mind to
start an IB module.
To answer your specific questions.
1) Of course it's "possible" - after all the Engine does it.
Is it possible short of emulating the engine? - no.
Your solution of passing new information in the XSQLDVAR
structure is the right one, but, of course, that means
XSQLDA becomes XSQLDA2, 2 formats to support (or 3 if
"old" SQLDA hasn't gone away yet). Client vs server
mismatch fixups, etc. In other words, a fairly messy
project.
2) I wouldn't worry about the cache being invalidated.
Interbase itself caches lots of metadata info that
becomes invalid with dynamic DDL updates. The idea
of dynamic DDL is it's rare -- occurs a lot during
development, but only rarely in a production db.
And even then, hopefully when the system is down
for an upgrade.
2b) I suspect you're doing individual queries to access
the pieces of information. I suggest you compose
a join and that should get some performance improvements.
As a starting point, look at how isql does extract
of precision information.
Dave
-----Original Message-----
From: woodsplitter.rm [mailto:woodsplitter@...]
Sent: Tuesday, May 14, 2002 4:10 PM
To: IB-Architect@yahoogroups.com
Subject: [IB-Architect] Best way to determine field precision?
I'm maintaining and enhancing an Interbase/Firebird driver for
Python ( http://kinterbasdb.sourceforge.net ). Python's standard
database API requires that the driver return the precision of SELECTed
fields. I'm talking about *precision* here, not *scale* (which is
already provided by the IB API as XSQLVAR.sqlscale). For example, in
a NUMERIC(18,2) field, precision is 18.
It's obvious that, given the relation name and field name of a
SELECTed field, one can determine its precision by querying the system
tables, but there are two problems with this approach:
1. The relation name and field name of a SELECTed field are not always
provided by the IB API, as in the case of a dynamically computed field
(e.g., "SELECT x/2 FROM SOME_TABLE").
Is there *any* way to programmatically determine the field's
precision in this case?
2. Performance is terrible.
In the worst case, one must query not just one or two system tables,
but several, first to determine whether XSQLVAR.relname refers to a
table, stored procedure, or view; then to retrieve the "internal name"
of the field in question (e.g., RDB$744); finally to retrieve the
field's precision from RDB$FIELDS.
Because of the requirements of the Python DB API 2.0, this process
must be performed for every field of every SELECT query when the query
is executed. It would be possible to cache the results, except that
the field's precision might in theory be ALTERed, invalidating the
cache.
So, is it possible to determine a SELECTed field's precision in
*every* case, and can it be done with decent performance? Ideally,
the API would provide XSQLVAR.sqlprecision along with
XSQLVAR.sqlscale.
Thanks.
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/