Hi Mariano,
here is a small test to reproduce the problem.
Cheers,

Alain

  "Mariano Martinez Peck" <[email protected]> a écrit dans le message de 
news: CAA+-=mUQtO+BRB3zWxcM904M_acNcAbjHNyXCjyGx4=+6f0...@mail.gmail.com...



  On Tue, Aug 16, 2011 at 8:46 AM, Alain Rastoul <[email protected]> wrote:

    Hi Mariano,
    Yes, that is what is expected, but in the case of SQLite, the column type 
changes to  SQLITE_NULL for nulls and that is a problem in squeakdbx now.
    I think column datatype should not be stored in the resultset in the case 
of sqlite.
    Other databases don't behave this way (as far as I can remember), so, 
overriding moveNext for sqlite would probably be fine.


  So yes. Something is needed for Sqlite so that the column type and friends 
are fetched for every raw or at least when there is an unknown. 
  At least there is a DBXSqlitePlatform that let you easily overwrite stuff ;)

   
    Cheers
    Alain
      "Mariano Martinez Peck" <[email protected]> a écrit dans le message 
de news: 
CAA+-=mWHq6X9JGz-5qTyb3z5ZqdUwMwBV06B5AEZ=ivzve4u4g-jsoawuisxosn+bqq9rb...@public.gmane.org...
      And here: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage

       I can read:

      " 
      Processing results 
      After fetching a row, all values of this row are available for further 
processing, as well as their name, length and type - but the name and the type 
of a column won't change. Also the number of columns returned by 
odbx_column_count() is fixed for the whole result. 

int i;

for( i = 0; i < odbx_column_count( result ); i++ )
{
    fprintf( stdout, "Name: %s\n", odbx_column_name( result, i ) );
    fprintf( stdout, "Type: %d\n", odbx_column_type( result, i ) );
    fprintf( stdout, "Length: %d\n", odbx_field_length( result, i ) );
    fprintf( stdout, "Value: %s\n", odbx_field_value( result, i ) );
}

      Besides odbx_column_type() these functions don't return error codes. 
Instead, they return zero (odbx_field_length()) or NULL (odbx_column_name() and 
odbx_field_length()), but you shouldn't check for those because these values 
are also valid return values. 

      All numbers are returned as strings from the database regardless if they 
are integers or floats. If you want to do arithmetic operations, you have to 
convert them to their machine dependent binary representation first. 

      "


      On Mon, Aug 15, 2011 at 11:11 PM, Mariano Martinez Peck 
<[email protected]> wrote:




        On Mon, Aug 15, 2011 at 9:59 PM, Alain Rastoul <[email protected]> wrote:

          Hi,
          I finally found that when called in C with the same api calls that 
those made by opendbx, sqlite correctly returns datatype of columns when 
fetching rows, the problem is clearly that the data type is stored in SQueakDBX 
column description for the resultset  the first time it fetches the first row.
          For sqlite, squeakdbx should call the sqlite api to retrieve column 
datatype for each row and each colum while fetching data.

        Hi Alain. I am reading this: 
http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_column_type

        From SqueakDBX, we send odbx_column_type ONCE PER RESULTSET. 
        You can see this in #processNextResultSet:querySettings:  that for 
every resultset it sends  #processResultWithRows:resultHandle:querySettings:

        Now.... should we send odbx_column_type and friends ONCE PER RAW? As 
far as I can see, in other databases we don't need to do that. But maybe we are 
wrong and you are right. 
        Norbert?

        Anyway, if you want to give it a try to Sqlite, what about overwrite 
#moveNext:  in SqlitePlatform and do something to set the new type for every 
raw. 

        From what I can see, if the type depends on each raw and it should be 
asked for every raw, then a design change is needed so that we can move the 
description from the REsultSet to the Raw :)
              


          But it may have implications I don't know.  Perhaps squeakDbx could 
get only true object values (are rawValues really needed) ?.

        Well, it depends on the user needs. Now, a key point is what GLORP 
should use. 
         
          Or perhaps another solution would be to call the sqlite api if the 
stored datatype is UNKNOWN in column description ... (only for sqlite, but 
sounds like a bad trick)

        sounds like a hask, but if it works it is at least a valid workaround. 
         
          I am perplexed ...

          Any idea is welcome

          Cheers 
          Alain
            "Mariano Martinez Peck" <[email protected]> a écrit dans le 
message de news: 
CAA+-=mw69g-mp3fqutj9vvhajrop9ezdv5z0zkv9junyzetykw-jsoawuisxosn+bqq9rb...@public.gmane.org...



            On Sat, Aug 13, 2011 at 12:06 AM, Alain Rastoul <[email protected]> 
wrote:

              It doen't work.
              Howerver googling for opendbx msg00483, I found
              
http://www.mail-archive.com/libopendbx-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg00483.html

            yes, that one :)
             
              it seems to be the problem of the issue 10, and I think the same 
problem I have..

            yes 
            Sorry, I cannot do more....  :(
             
              Strange that it doesn't work with MSSQL too..

                "Mariano Martinez Peck" <[email protected]> a écrit dans le 
message de news: 
CAA+-=mW4rwrLMhMAzsLhQ5zEWZBG_Jg=BF2dKu3wsxw0=io=i...@mail.gmail.com...



                On Fri, Aug 12, 2011 at 11:14 PM, Alain Rastoul 
<[email protected]> wrote:

                  I used the following script (about  2 months ago I think ) in 
Pharo 1.3

                  "SqueakDBX"
                  Gofer new squeaksource: 'MetacelloRepository';
                  package: 'ConfigurationOfSqueakDBX';
                  load.
                  ConfigurationOfSqueakDBX project latestVersion load.

                  "GLORP"
                  Gofer new squeaksource: 'MetacelloRepository';
                  package: 'ConfigurationOfGlorpDBX';
                  load.
                  ConfigurationOfGlorpDBX project latestVersion load.



                Yes, you are using SqueakDBX ;)  you will move soon to DBXTalk 
:)
                 
                  II use DBXTestCase for my  test with the code I send in my 
email (is it ok for you?), but I will have alook at DBXQueryTest too.
                  No problem to put it in the test suite - it makes me remember 
that I still didn't send my license agreement to Stephane but I will do it 
asap... I hate papers ;-)

                in our case we don't need that ;)
                 
                  
http://www.mail-archive.com/libopendbx-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg00483.html
                  The link is broken 


                
http://www.mail-archive.com/libopendbx-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg00483.html
 



                this one works?


                -- 
                Mariano
                http://marianopeck.wordpress.com





            -- 
            Mariano
            http://marianopeck.wordpress.com





        -- 
        Mariano
        http://marianopeck.wordpress.com





      -- 
      Mariano
      http://marianopeck.wordpress.com




--------------------------------------------------------------------------


      
------------------------------------------------------------------------------
      uberSVN's rich system and user administration capabilities and model 
      configuration take the hassle out of deploying and managing Subversion 
and 
      the tools developers use with it. Learn more about uberSVN and get a free 
      download at:  http://p.sf.net/sfu/wandisco-dev2dev



--------------------------------------------------------------------------





    
------------------------------------------------------------------------------
    uberSVN's rich system and user administration capabilities and model
    configuration take the hassle out of deploying and managing Subversion and
    the tools developers use with it. Learn more about uberSVN and get a free
    download at:  http://p.sf.net/sfu/wandisco-dev2dev

    _______________________________________________
    libopendbx-devel mailing list
    [email protected]
    https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
    http://www.linuxnetworks.de/doc/index.php/OpenDBX





  -- 
  Mariano
  http://marianopeck.wordpress.com

'From Pharo1.3 of 16 June 2011 [Latest update: #13269] on 16 August 2011 at 
9:32:27 pm'!
Smalltalk renameClassNamed: #DBXNullsTest as: #DBXNullsTest!
DBXBaseTest subclass: #DBXNullsTest
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Stargom-Tests'!

!DBXNullsTest methodsFor: 'running' stamp: 'AlainRastoul 8/15/2011 21:22'!
runDDLSetUpScript: aConnection 
        aConnection execute: 'drop table  if exists foo'.
        aConnection execute: 'create table foo (id int not null, name 
varchar(64) null )'.
! !

!DBXNullsTest methodsFor: 'running' stamp: 'AlainRastoul 8/16/2011 21:31'!
runDDLTearDownScript: aConnection
        aConnection execute:  'drop table foo'.
! !

!DBXNullsTest methodsFor: 'running' stamp: 'AlainRastoul 8/16/2011 21:25'!
runDMLSetUpScript: aConnection 
        aConnection execute: 'insert into foo values(1,  null  )'.
        aConnection execute:  'insert into foo values(2, ''riptobe'' )'.
! !

!DBXNullsTest methodsFor: 'tests' stamp: 'AlainRastoul 8/16/2011 21:26'!
testReadTableWithNull
" test reading of a null value in first line."
"In an inspector on the DBXRow:
OpenDBX current apiQueryColumns: (self resultSet handle)

self resultSet connection platform 
 descriptionForColumn: 2
 handle: (self resultSet handle)
 on: (self resultSet connection ).

"
        | conn stmt resultSet coll rows |
        conn := self doConnectAndOpen.
        [resultSet  := conn execute: 'SELECT id, name FROM foo'.
        coll := OrderedCollection new.
        rows := resultSet rows.
        rows  do: [ :r | coll add: r values ].
        self assert: (((coll at: 2) at: 2) isString).
        ] ensure: [ conn disconnect ].
! !

DBXNullsTest removeSelector: #initialize!
DBXNullsTest removeSelector: #platform!
DBXNullsTest removeSelector: #readTableWithNull!
DBXNullsTest removeSelector: #setUp!
DBXNullsTest removeSelector: #settings!
DBXNullsTest removeSelector: #tearDown!

!DBXNullsTest reorganize!
('running' runDDLSetUpScript: runDDLTearDownScript: runDMLSetUpScript:)
('tests' testReadTableWithNull)
!

Reply via email to