Hi Dan,
What is certainly happening is that Myosotis does a similar check and
might see that the field type is an oid where in fact we have stuffed it
with bytes. I am not sure what's best, either update the Field to
reflect the new type in the BackendObjectConverter or have Myosotis
handle the "oid" type in a specific way to fetch bytes instead of the
oid value.
You can check with Gilles and the Myosotis folks.
Keep me posted,
Emmanuel
I tried switching the getBlob to getBytes and it seems Sequoia is happy
now, but I get this from Myosotis.
java.sql.SQLException: the value [...@12611a7 is not a valid long number
at
org.continuent.sequoia.driver.DriverResultSet.getLong(DriverResultSet.ja
va:975)
at
org.continuent.myosotis.protocol.postgresql.PostgreSQLProtocolHandler.se
ndResultSet(PostgreSQLProtocolHandler.java:870)
It tried to read it as a long, now I am guessing this is probably
something in Myosotis. If you can confirm that just so I'm not going
crazy then I shall say thanks very much for the help and head off to the
Myosotis source/mailing list.
Thanks,
Dan McFadyen
-----Original Message-----
From: [email protected] [mailto:sequoia-
[email protected]] On Behalf Of Emmanuel Cecchet
Sent: January 30, 2009 8:49 AM
To: Sequoia general mailing list
Subject: Re: [Sequoia] Getting binary data from a postgres backend
Hi Dan,
Sequoia is transparent in the sense that it only perform the
transactions that you are asking it to do. There might be a setting in
Myosotis to encapsulate calls in transactions but I am not familiar
enough with Myosotis.
Otherwise, you are right, you will have to update your code to make
calls to LOBs within a transaction.
Before altering your code, you might want to try a call to getByte
instead of getBlob in the BackendObjectConverter just in case it would
work.
Thanks for the feedback,
Emmanuel
So, I made the change compiled and replaced it, and while it seems
to
be doing what it is supposed to do, it has found it a good idea to
inform me that "Large Objects man not be used in auto-commit mode."
Now, only thing I am curious about is if a change I make to my
connections auto commit mode will propagate all the way down or if I
have to change some configuration setting.
I'm hoping it can be a low end setting that won't affect the code,
but
I am going to guess that I am not so lucky....
All this because of no varbinary....
Thanks,
Dan McFadyen
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of
*Emmanuel Cecchet
*Sent:* January 29, 2009 10:09 AM
*To:* Sequoia general mailing list
*Subject:* Re: [Sequoia] Getting binary data from a postgres backend
Hi Dan,
Only thing I saw extra from the logs was:
2009-01-29 08:02:46,077 DEBUG
virtualdatabase.VirtualDatabaseWorkerThread.myDb statementExecute
command
If that's what I was supposed to get, I am not sure what it means to
you.
Well it just means that Sequoia has to figure out by itself whether
it
has to broadcast that call or not. This is just a different path in
the Sequoia code but that should not affect the way the result is
fetched.
Now, for a backend object converter. No sure what you mean but I am
going to guess it's something you can plug into Sequoia so that it
changes how it uses one of the backend databases. Does such a thing
already exist for Postgres? I can imagine if it didn't it would
cause
problems if you were using Postgres alongside a different DB type in
a
cluster as calls getting binary data would act different unless such
a
thing existed. And if that is true... why isn't the default behavior
to
do that? Sequoia seems to detect that it is dealing with Postgres
(unless I miss read the log).
If such a thing doesn't already exist, is there a place with some
documentation on how to make one?
Well, Robert announced that Continuent would release the uni/cluster
source code and this includes a BackendObjectConverter for Postgres.
The problem is that we don't know when this is going to happen.
Now, Sequoia does not really detect that the database is Postgres,
it
just reports what the database driver says. Sequoia 4 will have that
capacity to enforce pre-defined database specific extensions at the
virtual database level (instead of at the controller level in
Sequoia
2.10). Here is how you can modify the existing
SequoiaBackendObjectConverter in package
org.continuent.sequoia.controller.backend. There is a single
function
that is defined as follows:
public Object convertResultSetObject(ResultSet dbResultSet, int i,
Field f)
throws SQLException
{
Object object = dbResultSet.getObject(i + 1);
return object;
}
You have to test if the field is an oid and then call getBlob
instead
of getObject. Something like this would do:
public Object convertResultSetObject(ResultSet dbResultSet, int i,
Field f)
throws SQLException
{
Object object;
if (field.getTypeName().equals("oid"))
object = dbResultSet.getBlob(i + 1);
else
object = dbResultSet.getObject(i + 1);
return object;
}
Let me know if that works for you,
Emmanuel
Thanks,
Dan McFadyen
-----Original Message-----
From: [email protected]
<mailto:sequoia-
[email protected]> [mailto:sequoia-
[email protected]
<mailto:[email protected]>] On Behalf Of Emmanuel
Cecchet
Sent: January 28, 2009 3:05 PM
To: Sequoia general mailing list
Subject: Re: [Sequoia] Getting binary data from a postgres
backend
Dan,
Sequoia ships with isql (look in the bin/ directory) that is a
Java
client. You could check if you can retrieve all your data with
isql.
Another thing you can do is set the
log4j.logger.org.continuent.sequoia.controller.virtualdatabase.VirtualD
atabaseWorkerThread
logger to DEBUG in config/log4j.properties, it should tell you
what
kind
of call is will perform.
A caveat with Postgres is that Sequoia fetches ResultSets using
getObject which might return an oid instead of the data. If this
is
the
case, you need to use a special backend object converter that
will
call
getBlob instead of getObject.
Let us know what you see in the trace when you run with the
logger set
to DEBUG.
Thanks,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [email protected] <mailto:[email protected]>
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
<mailto:[email protected]>
https://forge.continuent.org/mailman/listinfo/sequoia
The information transmitted is intended only for the person or
entity
to which it is addressed and may contain confidential and/or
privileged
material. Statements and opinions expressed in this e-mail may not
represent those of the company. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance
upon, this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact
the sender immediately and delete the material from any computer.
Please see our legal details at http://www.cryptocard.com
CRYPTOCard Inc. is registered in the province of Ontario, Canada
with
Business number 80531 6478. CRYPTOCard Europe is limited liability
company registered in England and Wales (with registered number
05728808 and VAT number 869 3979 41); its registered office is Eden
Park, Ham Green, Bristol, BS20 0EB
_______________________________________________
Sequoia mailing list
[email protected]
<mailto:[email protected]>
https://forge.continuent.org/mailman/listinfo/sequoia
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [email protected] <mailto:[email protected]>
Skype: emmanuel_cecchet
The information transmitted is intended only for the person or
entity
to which it is addressed and may contain confidential and/or
privileged material. Statements and opinions expressed in this
e-mail
may not represent those of the company. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance
upon, this information by persons or entities other than the
intended
recipient is prohibited. If you received this in error, please
contact
the sender immediately and delete the material from any computer.
Please see our legal details at http://www.cryptocard.com
CRYPTOCard Inc. is registered in the province of Ontario, Canada
with
Business number 80531 6478. CRYPTOCard Europe is limited liability
company registered in England and Wales (with registered number
05728808 and VAT number 869 3979 41); its registered office is Eden
Park, Ham Green, Bristol, BS20 0EB
---------------------------------------------------------------------
---
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [email protected]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [email protected]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
