Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-06-17 Thread Toby Thain

On 17-Jun-09, at 10:03 AM, Markus Hoenicka wrote:

 Hi,

 Quoting Michael Friedrich michael.friedr...@univie.ac.at:

 I will need to step further into the driver but I wanted to ask

 * is the driver still in development or left alone?

 I'd say the driver is pretty much dormant. The latest oracle-specific
 changes have been committed approx. one year ago. According to what I
 read on the list, the driver is not in a shape that would allow us to
 call Oracle fully supported.

 * possibility of libdbi interface using parameter bindings

 Is that something like precompiled statements? This would be
 interesting to have, but I don't see sufficient developer resources to
 implement this anytime soon.


A good bullet point for libdbi-ng though, to join streamed  
results, and duck-typed column retrieval. (iirc)

--Toby


 regards,
 Markus


 -- 
 Markus Hoenicka
 markus.hoeni...@cats.de
 (Spam-protected email: replace the quadrupeds with mhoenicka)
 http://www.mhoenicka.de



 -- 
 
 Crystal Reports - New Free Runtime and 30 Day Trial
 Check out the new simplified licensing option that enables unlimited
 royalty-free distribution of the report engine for externally facing
 server and web deployment.
 http://p.sf.net/sfu/businessobjects
 ___
 Libdbi-drivers-devel mailing list
 Libdbi-drivers-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-04 Thread Markus Hoenicka
vincent rogier writes:
  For example, instead of using cached values (that need extra memory from
  dbbdi core module while the driver sometimes already hold cached values),
  the public dbdbi functions like dbi_result_get_int() could use callback to
  specific drivers functions that delivers the value.
  This would solve as well the problem of strong typed columns. It would be
  the driver to return the value as requested, whatever the real type of the
  column, making its own conversions. That's what OCILIB does. The application
  requests a column value with a desired type and OCILIB makes conversion if
  needed and possible.

The current cvs revision of libdbi has a lightweight variant of this
approach:

long long dbi_result_get_as_longlong();
long long dbi_result_get_as_longlong_idx();
char *dbi_result_get_as_string_copy();
char *dbi_result_get_as_string_copy_idx();

These functions return any value as either a long long integer or a
string after converting the value returned by the database
engine. Client programs can cast the integers to whatever they
need. I figured this would cover the most urgent needs.

  Introducing this possibility through callbacks would not break the actuals
  drivers. The libdbi core could check if the driver supports this feature and
  then call its functions. If not, it could work as it does now...
  

This is an interesting idea how to introduce this feature without
breaking backwards compatibility. Thanks for sharing this.

regards,
Markus

-- 
Markus Hoenicka
markus.hoeni...@cats.de
(Spam-protected email: replace the quadrupeds with mhoenicka)
http://www.mhoenicka.de

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-03 Thread Toby Thain


On 2-May-09, at 7:15 PM, vincent rogier wrote:

No, the sqllite trick cannot be used with Oracle... And even if it  
was possible, it is not a serious option because it would kill the  
driver performance People are still coding DB apps  in C


If it doesn't need to be database independent then there must be many  
efficient ways to code a C application against Oracle/{your db}.


because it's faster... If a C driver has to use exotics and slow  
behaviors to work, what's the point ?


The fact libdbi has to know the number of rows returned by a query,  
before any fetch,  is already a performance bottleneck for some DB,  
such as Oracle.


Agreed. This is a shortcoming of the libdbi API, in my opinion.




From Oracle 9i, it's possible to know that, with some big  
performance loss...(eg. Oracle 8i can't be supported)


In the end, the only thing that i need to finish the ocilib based  
libdbi driver is to solve this problem of integer flags and bits..


Any ideas ?


I think the API needs to change to support streamed access to result  
sets, and loosely typed columns (I suspect we'll see more of this in  
the future).


--Toby
(implementor of libdbi Ingres driver)




Vincent


2009/5/3 Markus Hoenicka markus.hoeni...@mhoenicka.de
vincent rogier writes:
  So, i'm still suck in the ocilib based libdbo driver to set the  
integer type
  bit... For example, a column created as INT (4 bytes integer  
range) or
  NUMBER (38 digits for scale and precision that can holds  
integer, numeric,
  real, etc..) will be reported by Oracle client library (OCI) as  
NUMBER...

  There's no way to make nay difference...
 
  So my question : how to deal with that into an libdbi driver ?
 

The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite
is essentially typeless, so you can't even distinguish between numbers
and text. sqlite3 has something like sticky types but these
distinguish only between text and numeric data. The sqlite/sqlite3
drivers have to retrieve the command which was used to create a table
(this is fortunately stored in each sqlite database) and figure out
which type to use as a return value. This approach has its problems
(think functions which mangle values retrieved from several columns)
but it mostly works ok. Would that approach be useful for an ocilib
based driver?

  PS : about the actual oracle libdbi driver : the driver can't  
even compile
  (syntax problems) and is wrong (LONG types, etc..) and buggy.  
I'm sure no

  one has tested it...
 

AFAIK there is no current oracle driver maintainer. Several people
have fiddled with the code in the past, but at this time hardly anyone
is able to even run the tests in lack of an Oracle installation. It
may very well be true that the driver is broken. I can't verify this.

regards,
Markus

--
Markus Hoenicka
markus.hoeni...@cats.de
(Spam-protected email: replace the quadrupeds with mhoenicka)
http://www.mhoenicka.de



--
Vincent Rogier
-- 


Register Now  Save for Velocity, the Web Performance  Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance  Operations tracks. Use code  
vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/ 
velocityconf___

Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-03 Thread vincent rogier
Hi toby,

If it doesn't need to be database independent then there must be many
efficient ways to code a C application against Oracle/{your db}.

True... that's why OCILIB exists :)

But implementing an underlying DB layer in a database independent framework
can be in tricky (for example : Oracle, actual libdbi driver is broken an
incomplete) and reusing existing optimized libraries (like OCILIB) is, i
think, a good thing because there is no need to reimplement the layer from
scratch.

I think, as well, that libdbi should evolve and allow the driver to provide
the data when requested by the user.
At the moment, libdbi core caches the results when the query is executed and
thus has to have a internal strong typed columns model.
It would be nice to introduce the possibility for the driver to supply
directly the data/informations.
For example, instead of using cached values (that need extra memory from
dbbdi core module while the driver sometimes already hold cached values),
the public dbdbi functions like dbi_result_get_int() could use callback to
specific drivers functions that delivers the value.
This would solve as well the problem of strong typed columns. It would be
the driver to return the value as requested, whatever the real type of the
column, making its own conversions. That's what OCILIB does. The application
requests a column value with a desired type and OCILIB makes conversion if
needed and possible.
Introducing this possibility through callbacks would not break the actuals
drivers. The libdbi core could check if the driver supports this feature and
then call its functions. If not, it could work as it does now...

What do you think, Markus ?

ps : sorry for my poor English...

Vincent.

2009/5/3 Toby Thain t...@telegraphics.com.au


 On 2-May-09, at 7:15 PM, vincent rogier wrote:

 No, the sqllite trick cannot be used with Oracle... And even if it was
 possible, it is not a serious option because it would kill the driver
 performance People are still coding DB apps  in C


 If it doesn't need to be database independent then there must be many
 efficient ways to code a C application against Oracle/{your db}.

 because it's faster... If a C driver has to use exotics and slow behaviors
 to work, what's the point ?

 The fact libdbi has to know the number of rows returned by a query, before
 any fetch,  is already a performance bottleneck for some DB, such as Oracle.


 Agreed. This is a shortcoming of the libdbi API, in my opinion.



 From Oracle 9i, it's possible to know that, with some big performance
 loss...(eg. Oracle 8i can't be supported)

 In the end, the only thing that i need to finish the ocilib based libdbi
 driver is to solve this problem of integer flags and bits..

 Any ideas ?


 I think the API needs to change to support streamed access to result sets,
 and loosely typed columns (I suspect we'll see more of this in the future).

 --Toby
 (implementor of libdbi Ingres driver)



 Vincent


 2009/5/3 Markus Hoenicka markus.hoeni...@mhoenicka.de

 vincent rogier writes:
   So, i'm still suck in the ocilib based libdbo driver to set the integer
 type
   bit... For example, a column created as INT (4 bytes integer range)
 or
   NUMBER (38 digits for scale and precision that can holds integer,
 numeric,
   real, etc..) will be reported by Oracle client library (OCI) as
 NUMBER...
   There's no way to make nay difference...
  
   So my question : how to deal with that into an libdbi driver ?
  

 The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite
 is essentially typeless, so you can't even distinguish between numbers
 and text. sqlite3 has something like sticky types but these
 distinguish only between text and numeric data. The sqlite/sqlite3
 drivers have to retrieve the command which was used to create a table
 (this is fortunately stored in each sqlite database) and figure out
 which type to use as a return value. This approach has its problems
 (think functions which mangle values retrieved from several columns)
 but it mostly works ok. Would that approach be useful for an ocilib
 based driver?

   PS : about the actual oracle libdbi driver : the driver can't even
 compile
   (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure
 no
   one has tested it...
  

 AFAIK there is no current oracle driver maintainer. Several people
 have fiddled with the code in the past, but at this time hardly anyone
 is able to even run the tests in lack of an Oracle installation. It
 may very well be true that the driver is broken. I can't verify this.

 regards,
 Markus

 --
 Markus Hoenicka
 markus.hoeni...@cats.de
 (Spam-protected email: replace the quadrupeds with mhoenicka)
 http://www.mhoenicka.de




 --
 Vincent Rogier

 --
 Register Now  Save for Velocity, the Web Performance  Operations
 Conference from O'Reilly Media. Velocity features a full day of
 expert-led, hands-on 

Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-03 Thread vincent rogier
Hi Christian,

Few hints about  the actual Oracle driver :

- it cannot compile with a C90 compiler (one line of code to fix to make it
compile).
- LONG type is handled as an integer instead of a character based type
- only few types are handled and all types mapped as strings
- numeric types are not handled properly (because of strong libdbi integer
typing)
- no support for Oracle 8i
- output buffers are unnecessary defined at every fetch call

The actual driver would need just few fixed and changes to be fully and
properly usable. That's an option.

I contacted Markus a while ago to propose him to make a oracle driver based
of ocilib. Because it was a easy and quick job to implement a driver with
OCILIB as it's a full featured and mature library. And using it would allow
to have light libdbi glue and let OCILIB work with all Oracle internal
details and deal with Oracle versions and new features. By example, new
floatting types where addind on 10g and using ocilib, the libdbi glue
wouldn't need to be modified. On thing as well, is the runtime Oracle
version handling by OCILIB that ajusts its capabilities depending on the
Oracle version...etc, ...

Anyway, if Markus prefers, i could see and try to fix and update the actual
driver.

I'm not trying to push ocilib into libdbi, i don't need it..
i just wanted to help :)

Vincent.


2009/5/3 Christian Stamgren c...@stamgren.com

 Hi All,

 Being the guy who wrote the Oracle driver long time ago (as well as the
 Firebird and mSQL drivers).

 Yes, the driver is not completed. There was work left todo when I left the
 maintainership over to someone else. Unfortunately that someone else didn't
 finish it either. Most probably he broke more then he fixed as the driver
 did compile and worked fine in the few projects I used it against (Oracle
 9i) when I still took care of it.

 I think it should be fairly easy to make it work again, although I am not
 the one that is going to do it. Building a new driver based on a third party
 library might be a way forward. But that would be a layer on a layer
 solution. If I where the one coding I would focus on fixing the current
 Oracle driver that uses OCI directly, not to build a new module from
 scratch.
 But as I am not the one coding I would just be happy to get a working
 driver for Oracle based on anything. So if you are writhing this driver and
 planning to maintain it, go for it, exchange the oracle driver with your
 driver.

 All the best,

 Christian


 On May 2, 2009, at 9:45 PM, vincent rogier wrote:

  Hi markus,

 I'm coming back about an ocilib based Oracle driver for libdbi.

 About FreeBSD, There's no official support or package from Oracle Corp.
 A port has been done and seems to work. The last few weeks, i was in
 contact with an italian that tried to port OCILIB to FreeBSD.
 OCILIB compiles well on FreeBDS but there is a problem with the version of
 the lib C used for the Oracle Client port.
 I'm still waiting for news...

 So, the last package i sent you was working well except the numeric types
 problems...
 It's not possible to know what size a numeric value really is (1/2/4/8
 bytes integers or even numeric...)
 When you create an INT column or a SHORT column, the storage is the same :
 oracle NUMBER. Even SQL*PLUS would cannot make the difference. Only the
 server knows the difference for range checking..

 Oracle is different from other database because the client program that
 tells Oracle how it wants to retreive/insert the value.

 So, i'm still suck in the ocilib based libdbo driver to set the integer
 type bit... For example, a column created as INT (4 bytes integer range)
 or NUMBER (38 digits for scale and precision that can holds integer,
 numeric, real, etc..) will be reported by Oracle client library (OCI) as
 NUMBER... There's no way to make nay difference...

 So my question : how to deal with that into an libdbi driver ?

 PS : about the actual oracle libdbi driver : the driver can't even compile
 (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no
 one has tested it...

 Regards,

 Vincent.

 2008/11/13 Markus Hoenicka markus.hoeni...@mhoenicka.de
 vincent rogier writes:
   I believe it would be more appropriate to call the driver ocilib
  
   Sure :). I'll change that
  

 Don't rush it. I hoped to get some feedback about the status and the
 capabilities of the existing oracle driver (which I can't test
 myself). If the ocilib driver surpasses the oracle driver and is
 better maintained, then the existing driver is obsolete and should be
 replaced by the ocilib driver. In that case, oracle wouldn't be a
 misnomer. However, if for some reason both drivers have to coexist,
 I'd rather avoid the name clash.

   Btw, i've got one question about libdbi integer types...
  
   Oracle does not make any difference between 1, 2, 4 or 8 bytes integer
 (from
   an OCI point of vue).
   So, as far i've seen about libdbi implementation of datatype (use of
 unions
   and 

Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-03 Thread Christian Stamgren
Hi Vincent,

You do what is easiest for you, personally iI would like if the  
current driver using oracle OCI would be fixed but it is not up to me,  
as I am not going to write it, but it feels kosher for libdbi to use  
the database own library.

There is a list of things I wanted to do in the driver directory  
written in a file named TODO, those together with your list gives a  
pretty accurate list of what the driver needs if you choose to fix the  
current one. But as I said that is up to you.


Thanks for your work.

Christian


On May 3, 2009, at 8:56 PM, vincent rogier wrote:

 Hi Christian,

 Few hints about  the actual Oracle driver :

 - it cannot compile with a C90 compiler (one line of code to fix to  
 make it compile).
 - LONG type is handled as an integer instead of a character based type
 - only few types are handled and all types mapped as strings
 - numeric types are not handled properly (because of strong libdbi  
 integer typing)
 - no support for Oracle 8i
 - output buffers are unnecessary defined at every fetch call

 The actual driver would need just few fixed and changes to be fully  
 and properly usable. That's an option.

 I contacted Markus a while ago to propose him to make a oracle  
 driver based of ocilib. Because it was a easy and quick job to  
 implement a driver with OCILIB as it's a full featured and mature  
 library. And using it would allow to have light libdbi glue and let  
 OCILIB work with all Oracle internal details and deal with Oracle  
 versions and new features. By example, new floatting types where  
 addind on 10g and using ocilib, the libdbi glue wouldn't need to be  
 modified. On thing as well, is the runtime Oracle version handling  
 by OCILIB that ajusts its capabilities depending on the Oracle  
 version...etc, ...

 Anyway, if Markus prefers, i could see and try to fix and update the  
 actual driver.

 I'm not trying to push ocilib into libdbi, i don't need it..
 i just wanted to help :)

 Vincent.


 2009/5/3 Christian Stamgren c...@stamgren.com
 Hi All,

 Being the guy who wrote the Oracle driver long time ago (as well as  
 the Firebird and mSQL drivers).

 Yes, the driver is not completed. There was work left todo when I  
 left the maintainership over to someone else. Unfortunately that  
 someone else didn't finish it either. Most probably he broke more  
 then he fixed as the driver did compile and worked fine in the few  
 projects I used it against (Oracle 9i) when I still took care of it.

 I think it should be fairly easy to make it work again, although I  
 am not the one that is going to do it. Building a new driver based  
 on a third party library might be a way forward. But that would be a  
 layer on a layer solution. If I where the one coding I would focus  
 on fixing the current Oracle driver that uses OCI directly, not to  
 build a new module from scratch.
 But as I am not the one coding I would just be happy to get a  
 working driver for Oracle based on anything. So if you are writhing  
 this driver and planning to maintain it, go for it, exchange the  
 oracle driver with your driver.

 All the best,

 Christian


 On May 2, 2009, at 9:45 PM, vincent rogier wrote:

 Hi markus,

 I'm coming back about an ocilib based Oracle driver for libdbi.

 About FreeBSD, There's no official support or package from Oracle  
 Corp.
 A port has been done and seems to work. The last few weeks, i was in  
 contact with an italian that tried to port OCILIB to FreeBSD.
 OCILIB compiles well on FreeBDS but there is a problem with the  
 version of the lib C used for the Oracle Client port.
 I'm still waiting for news...

 So, the last package i sent you was working well except the numeric  
 types problems...
 It's not possible to know what size a numeric value really is  
 (1/2/4/8 bytes integers or even numeric...)
 When you create an INT column or a SHORT column, the storage is the  
 same : oracle NUMBER. Even SQL*PLUS would cannot make the  
 difference. Only the server knows the difference for range checking..

 Oracle is different from other database because the client program  
 that tells Oracle how it wants to retreive/insert the value.

 So, i'm still suck in the ocilib based libdbo driver to set the  
 integer type bit... For example, a column created as INT (4 bytes  
 integer range) or NUMBER (38 digits for scale and precision that  
 can holds integer, numeric, real, etc..) will be reported by Oracle  
 client library (OCI) as NUMBER... There's no way to make nay  
 difference...

 So my question : how to deal with that into an libdbi driver ?

 PS : about the actual oracle libdbi driver : the driver can't even  
 compile (syntax problems) and is wrong (LONG types, etc..) and  
 buggy. I'm sure no one has tested it...

 Regards,

 Vincent.

 2008/11/13 Markus Hoenicka markus.hoeni...@mhoenicka.de
 vincent rogier writes:
   I believe it would be more appropriate to call the driver ocilib
  
   Sure :). I'll change that
  

Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-02 Thread vincent rogier
Hi markus,

I'm coming back about an ocilib based Oracle driver for libdbi.

About FreeBSD, There's no official support or package from Oracle Corp.
A port has been done and seems to work. The last few weeks, i was in contact
with an italian that tried to port OCILIB to FreeBSD.
OCILIB compiles well on FreeBDS but there is a problem with the version of
the lib C used for the Oracle Client port.
I'm still waiting for news...

So, the last package i sent you was working well except the numeric types
problems...
It's not possible to know what size a numeric value really is (1/2/4/8 bytes
integers or even numeric...)
When you create an INT column or a SHORT column, the storage is the same :
oracle NUMBER. Even SQL*PLUS would cannot make the difference. Only the
server knows the difference for range checking..

Oracle is different from other database because the client program that
tells Oracle how it wants to retreive/insert the value.

So, i'm still suck in the ocilib based libdbo driver to set the integer type
bit... For example, a column created as INT (4 bytes integer range) or
NUMBER (38 digits for scale and precision that can holds integer, numeric,
real, etc..) will be reported by Oracle client library (OCI) as NUMBER...
There's no way to make nay difference...

So my question : how to deal with that into an libdbi driver ?

PS : about the actual oracle libdbi driver : the driver can't even compile
(syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no
one has tested it...

Regards,

Vincent.

2008/11/13 Markus Hoenicka markus.hoeni...@mhoenicka.de

 vincent rogier writes:
   I believe it would be more appropriate to call the driver ocilib
  
   Sure :). I'll change that
  

 Don't rush it. I hoped to get some feedback about the status and the
 capabilities of the existing oracle driver (which I can't test
 myself). If the ocilib driver surpasses the oracle driver and is
 better maintained, then the existing driver is obsolete and should be
 replaced by the ocilib driver. In that case, oracle wouldn't be a
 misnomer. However, if for some reason both drivers have to coexist,
 I'd rather avoid the name clash.

   Btw, i've got one question about libdbi integer types...
  
   Oracle does not make any difference between 1, 2, 4 or 8 bytes integer
 (from
   an OCI point of vue).
   So, as far i've seen about libdbi implementation of datatype (use of
 unions
   and checks on the integer type flag), there 's no easy and pretty way to
   deal with it does all other libbdi drivers have no problems like
 that ?
  

 SQlite is essentially typeless. I.e. it won't even distinguish between
 text and integer. SQLite3 has something called column affinities
 which helps to distinguish between text and other data types. However,
 there is no support for different integer types either.

 The sqlite/sqlite3 drivers use whatever type the column was declared
 with. Although it doesn't make a difference to SQLite, you *can*
 declare a column as TINYINT, SMALLINT, INTEGER, or BIGINT, and the
 drivers rely on you (as a programmer) doing so. OTOH, SQLite wouldn't
 barf if you store a long long value in a column declared as
 TINYINT. You wouldn't even lose data if you retrieve the value with
 sqlite. libdbi would reduce the data to a 1 byte integer upon
 retrieval though.


 How does Oracle deal with this? Is there just one integer type? What
 size is it? Are there any compatibility types to deal with imported
 data, like MySQL and other engines do?

 regards,
 Markus

 --
 Markus Hoenicka
 markus.hoeni...@cats.de
 (Spam-protected email: replace the quadrupeds with mhoenicka)
 http://www.mhoenicka.de




-- 
Vincent Rogier
--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-02 Thread Markus Hoenicka
vincent rogier writes:
  So, i'm still suck in the ocilib based libdbo driver to set the integer type
  bit... For example, a column created as INT (4 bytes integer range) or
  NUMBER (38 digits for scale and precision that can holds integer, numeric,
  real, etc..) will be reported by Oracle client library (OCI) as NUMBER...
  There's no way to make nay difference...
  
  So my question : how to deal with that into an libdbi driver ?
  

The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite
is essentially typeless, so you can't even distinguish between numbers
and text. sqlite3 has something like sticky types but these
distinguish only between text and numeric data. The sqlite/sqlite3
drivers have to retrieve the command which was used to create a table
(this is fortunately stored in each sqlite database) and figure out
which type to use as a return value. This approach has its problems
(think functions which mangle values retrieved from several columns)
but it mostly works ok. Would that approach be useful for an ocilib
based driver?

  PS : about the actual oracle libdbi driver : the driver can't even compile
  (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure no
  one has tested it...
  

AFAIK there is no current oracle driver maintainer. Several people
have fiddled with the code in the past, but at this time hardly anyone
is able to even run the tests in lack of an Oracle installation. It
may very well be true that the driver is broken. I can't verify this.

regards,
Markus

-- 
Markus Hoenicka
markus.hoeni...@cats.de
(Spam-protected email: replace the quadrupeds with mhoenicka)
http://www.mhoenicka.de

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel


Re: [Libdbi-drivers-devel] libdbi oracle driver based on ocilib

2009-05-02 Thread vincent rogier
No, the sqllite trick cannot be used with Oracle... And even if it was
possible, it is not a serious option because it would kill the driver
performance People are still coding DB apps  in C because it's faster...
If a C driver has to use exotics and slow behaviors to work, what's the
point ?

The fact libdbi has to know the number of rows returned by a query, before
any fetch,  is already a performance bottleneck for some DB, such as Oracle.

From Oracle 9i, it's possible to know that, with some big performance
loss...(eg. Oracle 8i can't be supported)

In the end, the only thing that i need to finish the ocilib based libdbi
driver is to solve this problem of integer flags and bits..

Any ideas ?

Vincent


2009/5/3 Markus Hoenicka markus.hoeni...@mhoenicka.de

 vincent rogier writes:
   So, i'm still suck in the ocilib based libdbo driver to set the integer
 type
   bit... For example, a column created as INT (4 bytes integer range) or
   NUMBER (38 digits for scale and precision that can holds integer,
 numeric,
   real, etc..) will be reported by Oracle client library (OCI) as
 NUMBER...
   There's no way to make nay difference...
  
   So my question : how to deal with that into an libdbi driver ?
  

 The sqlite/sqlite3 drivers have to deal with a similar problem. sqlite
 is essentially typeless, so you can't even distinguish between numbers
 and text. sqlite3 has something like sticky types but these
 distinguish only between text and numeric data. The sqlite/sqlite3
 drivers have to retrieve the command which was used to create a table
 (this is fortunately stored in each sqlite database) and figure out
 which type to use as a return value. This approach has its problems
 (think functions which mangle values retrieved from several columns)
 but it mostly works ok. Would that approach be useful for an ocilib
 based driver?

   PS : about the actual oracle libdbi driver : the driver can't even
 compile
   (syntax problems) and is wrong (LONG types, etc..) and buggy. I'm sure
 no
   one has tested it...
  

 AFAIK there is no current oracle driver maintainer. Several people
 have fiddled with the code in the past, but at this time hardly anyone
 is able to even run the tests in lack of an Oracle installation. It
 may very well be true that the driver is broken. I can't verify this.

 regards,
 Markus

 --
 Markus Hoenicka
 markus.hoeni...@cats.de
 (Spam-protected email: replace the quadrupeds with mhoenicka)
 http://www.mhoenicka.de




-- 
Vincent Rogier
--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel