Sorry I missed this, thanks for the response.  Yeah I worked around it for now, sometimes these sql access layers set things that make sense but are out of your control.  That seems like a good nuclear option, but maybe if no one else cares Ill just stick with what I have.  BTW, I was using this library  It sets readOnly for asking about the metadata of each table...


On Thu, Jun 12, 2014 at 8:19 AM, Gabriel Reid <> wrote:
Hi Dan,

I've encountered a similar scenario with
Connection.setTransactionIsolation, which also throws a
SQLFeatureNotSupportedException. On the one hand, it's definitely
annoying to have little things like this getting in the way, but on
the other hand I'm not crazy about the idea of just logging a warning
for these features. An application may be doing things that are
actually dependent on these settings working, so I prefer the idea of
failing fast.

One idea might be to have a connection setting called
"ignoreUnsupportedFeatures" or something like that, and if it was set
to true then a warning could be logged instead of throwing
SQLFeatureNotSupportedException in case something like setReadOnly was
called. I think that would give a good balance of allowing getting
around this issue without sacrificing too much in correctness.

What do you think?

- Gabriel

On Thu, Jun 12, 2014 at 6:47 AM, Dan Di Spaltro <> wrote:
> I have a sql accessing library that I was hoping to use for phoenix, but
> they use readOnly connections to get the metadata.  As it stands Phoenix
> throws an exception when you set a conn as readOnly.  Do you think that
> would be reasonable to change this to a warning or remove the exception
> entirely.  I get the reasons not to, but I also don't want to change a bunch
> of code or keep a separate branch on something that would actually work,
> just not be 100% truthful.
> Thoughts?
> --
> Dan Di Spaltro

Dan Di Spaltro