Hello again,
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
