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 <[email protected]> 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
