Hi
I 'm writing a small app with pharo +seaside + glorp + squeakdbx + sqlite and I have a problem reading null values from my database. It seems that glorp stores a DbxTypeNotSupported in the column description for null values when the first row has a null value (the column datatype is varchar). Any workaround or advice is welcome before I dig into Glorp code TIA Alain |
On Thu, Aug 11, 2011 at 10:02 PM, Alain Rastoul <[hidden email]> wrote: Hi Hi Alain. Do you know exactly which query is being sent? Do you think it can be related to this: http://code.google.com/p/dbxtalk/issues/detail?id=10 ? It seems that glorp stores a DbxTypeNotSupported in the column description for null values when the first row has a null value (the column datatype is varchar). -- Mariano http://marianopeck.wordpress.com |
Hi Mariano
I may be wrong, but I don't think that this issue
is not related, I have first checked that reading
my data with squeakdbx is ok.
After searching a bit I think that the problem is
in Glorp in
DBXPlatform>>createDataTypesMap
"Creates and returns a map that maps Smalltalk classes to SQL datatypes. The 16r means it is hexadecimal." ^Dictionary new ...
at: 16rFF put: (DBXTypeNotSupported
type: #UNKNOWN);
Perhaps a solution would be I think it should be
something like
at: 16rFF put: (DBXTypeNotSupported type:
UndefinedObject);
with a fromDbxString method defined in
UndefinedObject.
fromDbxString: aString
^ convert the string to the true
column datatype
The problem here is that there should be a
conversion from the string to the column datatype and the column datatype is
unknown here...
I don't know either if it is possible to get it
from squeakdbx at this point (while fetching data) ?
|
Hi Alain!
where did you get GlorpDBX? :) Was it from the DBXTalk repo? On Thu, Aug 11, 2011 at 5:28 PM, Alain Rastoul <[hidden email]> wrote:
How did you read the data? Using values or raw values? Can you send us/me the query sent by glorp? Is it a polymorphic or inheritance query? Thanks! Guille
|
hi Guillermo,
you are right, I didn't use rawValues , and that
was the problem.
The problem is not with Glorp but with opendbx and
in fact it is the same as the issue pointed to by Mariano (issue 10) and another
(issue 16)
I have a simpler test to reproduce than yours (in
fact you don't need to use UNION in your test):
| settings dbc stmt resultSet coll | settings := DBXConnectionSettings host: SmalltalkImage current imagePath, '/' port: '' database: 'testdb.dat' userName: '' userPassword: ''. dbc := DBXConnection platform: DBXSqlitePlatform new settings: settings. [ dbc connect. dbc open. dbc execute: 'drop table if exists foo'. dbc execute: 'create table foo (id int not null, name varchar(64) null )'. dbc execute: 'insert into foo values(1, null )'. dbc execute: 'insert into foo values(2, ''riptobe'' )'. resultSet := dbc execute: 'SELECT * FROM foo'. coll := OrderedCollection new. "error here for null value in second row"
resultSet rows do: [ :r | coll add: r values ]. coll inspect. ] ensure: [ dbc close ]. The problem is that opendbx doesn't return the correct datatype for
columns when they have null values, apparently it keeps the description for the
column that was readen for the first row (?)
And the same problem exists with MSSQL, it is not related to the special
sqlite UNKNOW datatype but a problem in opendbx (my test also breaks with
mssql)
I am writing a test case for that, and I will also have a look at opendbx
source code.
Cheers
Alain
|
On Fri, Aug 12, 2011 at 9:39 PM, Alain Rastoul <[hidden email]> wrote:
Hi Alain. First of all, thanks for poiting out the bug. Now, Guille asked you how did you install SqueakDBX/GlorpDBX because we are VERY near to release a new version of the new project called DBXTalk in which we will release a new version of SqueakDBX, which will be called OpenDBXDriver and a new release of GlorpDBX and Glorp, which we port the latest version from VW. You will have more news very soon, but I recommend you to migrate to this new stuff once it is out.
I am out of time right now, but I would love if you or someone can take this piece of code and "adapt it" as a regular SqueakDBX test. If you do this, please do it directly in the package OpenDBXDriverTests of the repo http://www.squeaksource.com/DBXTalk. We really welcome your test :) You can add it to: DBXQueryTest. Take a look at to the existing tests there.
Can you confirm it is this problem? http://www.mail-archive.com/libopendbx-devel@.../msg00483.html If it is...then it seems there is no fix :(
excellent.
great. Don't be shy to ask to ask and OpenDBX mailing list.
-- Mariano http://marianopeck.wordpress.com |
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. 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 ;-) |
On Fri, Aug 12, 2011 at 11:14 PM, Alain Rastoul <[hidden email]> wrote:
Yes, you are using SqueakDBX ;) you will move soon to DBXTalk :)
in our case we don't need that ;) this one works? -- Mariano http://marianopeck.wordpress.com |
It doen't work.
Howerver googling for opendbx msg00483, I
found
it seems to be the problem of the issue 10, and I
think the same problem I have..
Strange that it doesn't work with MSSQL
too..
|
On Sat, Aug 13, 2011 at 12:06 AM, Alain Rastoul <[hidden email]> wrote:
yes, that one :)
yes Sorry, I cannot do more.... :(
-- Mariano http://marianopeck.wordpress.com |
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.
But it may have implications I don't know.
Perhaps squeakDbx could get only true object values (are rawValues really
needed) ?.
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)
I am perplexed ...
Any idea is welcome
Cheers
Alain
|
On Mon, Aug 15, 2011 at 9:59 PM, Alain Rastoul <[hidden email]> wrote:
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 :)
Well, it depends on the user needs. Now, a key point is what GLORP should use.
sounds like a hask, but if it works it is at least a valid workaround.
-- Mariano http://marianopeck.wordpress.com |
And here: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage
I can read: " Processing resultsAfter 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 ) ); }
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 <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
On Tue, Aug 16, 2011 at 8:46 AM, Alain Rastoul <[hidden email]> wrote:
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 ;)
-- Mariano http://marianopeck.wordpress.com |
Hi Mariano,
here is a small test to reproduce the
problem.
Cheers,
Alain
DBXNulls.3.cs (2K) Download Attachment |
Free forum by Nabble | Edit this page |