phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Di Spaltro <>
Subject Re: setReadOnly
Date Tue, 24 Jun 2014 22:49:40 GMT
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 <>

> 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

View raw message