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=ivzve4...@mail.gmail.com > ... > 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<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/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<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_column_type>() > these functions don't return error codes. Instead, they return zero ( > odbx_field_length<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_field_length>()) > or NULL > (odbx_column_name<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/odbx_column_name>() > and > odbx_field_length<http://www.linuxnetworks.de/doc/index.php/OpenDBX/API/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<http://www.mail-archive.com/[email protected]/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
