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
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?
On Thu, Jun 12, 2014 at 6:47 AM, Dan Di Spaltro <email@example.com> 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.
> Dan Di Spaltro