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 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
>>
>
>
--
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
