there is a misunderstanding here (I think).
the problem of the UNKNOWN type is not in OpenDBX but in the OpenDBXDriver. I
remember I added the type UNKNOWN to all the... well, unknown types :)
Since OpenDBX will give you a string with a timestamp, you can modify driver (a
Pharo chunk of code) to adapt to your needs, without needing to modify more.
for example (and always take into account that is been like 3yr since last time
I seen this):
when you instantiate a resultset you need to know the types, which comes from
OpenDBX as a number, so you need to:
detectNewTypes: aDBXResultSet
notSupportedDescriptions keysAndValuesDo:[ :index :desc | | dbxType |
dbxType := OpenDBX current apiQueryColumnType:
aDBXResultSet handle index: (index - 1) .
desc type: (aDBXResultSet dataTypeAt: dbxType);
dbxType: dbxType.
desc type isBehavior ifTrue:[
notSupportedDescriptions removeKey: index ] ]
as you can see, that calls DBXResultSet>>#dataTypeAt: which at his time calls
also #dataTypeAt: from the platform, who ends finally to answer something like
this:
at: 16rFF put: (DBXTypeNotSupported type: #UNKNOWN);
(in DBXBackend>>#createDataTypesMap)
So… my opinion is that you could twist something someplace there (like creating
your own platform backend, derivate from your real backend, who instead
DBXTypeNotSupported type: #UNKNOWN will answer TimeStamp). Of course this is an
ugly hack, but can solve your problem.
If you want to be sure that you just change the type for the scheme you want
and not for all possible UNKNOWN types, you can override dataTypeAt: in
DBXResultSet and check if the column you want to change is the one you want,
then you can force the type to the one you want.
Well… I can think in many other hacks that can solve your problem without
changing opendbx.so and without changing either Glorp :)
I suggest you to go in that direction.
cheers,
Esteban
> On 28 Oct 2014, at 22:01, bsselfri...@gmail.com wrote
>
> I've contacted the OpenDBX development group and they seem to be unwilling to
> add the "UNKNOWN" types to their library. So, that leaves us with solving
> the problem in the GLORP framework.
>
> The big problem is the GlorpOpenDbxDriver is asking the DBXRow for its value
> - not rawValue, thereby triggering the DBXTypeNotSupported object to throw
> an exception. My suggestion is that framework needs to be enhanced to deal
> with this problem and not force every developer to have to bypass/override
> chunks of the Glorp framework whenever an "UNKNOWN" type is returned.
>
> I have some ideas how to overcome this dilemma. However, I think that I may
> need to move this conversation to the Glorp group.
>
>
>
>
>
> -----
> Brad Selfridge
> --
> View this message in context:
> http://forum.world.st/Pharo-OpenDBXDriver-Unsupported-data-type-UNKNOWN-tp4785813p4787306.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
