RE: OPENJPA-182: reuse Connection constants or create our own?
I suggest that you either add a patch to the issue, or open a new
sub-issue that outlines this particular problem.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: Ritika Maheshwari [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 17, 2007 12:04 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or
> create our own?
>
> Patrick,
> we just discovered that there is a problem with
> this fix.Theproblem is that the FOR READ ONLY flag is getting
> generated for subselects as well.
>
> Basically for DB2 if forUpdate was false we append FOR READ
> ONLY we need another check to see that it is not a
> subselect.To me it appears that in the toSelect method when
> SelectImpl is passed we check that the parent is null or not
> to figure out that it is a subselect and then pass another
> flag subselect to the getForUdateClause method where we say
> if(!forUpdate && !subselect)
> forUpdateString.append(forReadOnlyClause)
> to achieve this we would probably have to override the
> toSelect methods in DB2Dictionary again unless there is a better way.
>
>
> On 4/10/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
> >
> > As long as any given enum instance that corresponds to a
> > theoretically-unique enum value has internally-consistent state, we
> > should be in good shape. IOW, if the enum constructors are called
> > appropriately or internal state is otherwise maintained,
> then things
> > should work out fine.
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> >
> __
> > _
> > Notice: This email message, together with any attachments, may
> > contain information of BEA Systems, Inc., its
> subsidiaries and
> > affiliated entities, that may be confidential, proprietary,
> > copyrighted and/or legally privileged, and is intended
> solely for the
> > use of the individual or entity named in this message. If
> you are not
> > the intended recipient, and have received this message in error,
> > please immediately return this by email and then delete it.
> >
> > > -----Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, April 10, 2007 4:56 PM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: Re: OPENJPA-182: reuse Connection constants or
> create our
> > > own?
> > >
> > > It should be ok anyway in the same VM. Unfortunately I had
> > > conflicting messages on weather it's the name or the
> ordinal that is
> > > guaranteed to work across the VMs :(.
> > >
> > > -marina
> > >
> > > Patrick Linskey wrote:
> > > > Fascinating. Happily, as it turns out, we never compare these
> > > > things directly; instead, we extract a value from the enums and
> > > use that. The
> > > > value is populated in the enum constructor:
> > > >
> > > > public enum IsolationLevel {
> > > > DEFAULT(-1),
> > > > NONE(Connection.TRANSACTION_NONE),
> > > > READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
> > > > READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
> > > > REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
> > > > SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
> > > >
> > > > private final int _connectionConstant;
> > > >
> > > > private IsolationLevel(int connectionConstant) {
> > > > _connectionConstant = connectionConstant;
> > > > }
> > > >
> > > > protected int getConnectionConstant() {
> > > > return _connectionConstant;
> > > > }
> > > > }
> > > >
> > > > Do you know if the getConnectionConstant() method would
> > > return the same
> > > > v
Re: OPENJPA-182: reuse Connection constants or create our own?
Patrick,
we just discovered that there is a problem with this
fix.Theproblem is that the FOR READ ONLY flag is getting generated for
subselects
as well.
Basically for DB2 if forUpdate was false we append FOR READ ONLY we need
another check to see that it is not a subselect.To me it appears that in the
toSelect method when SelectImpl is passed we check that the parent is null
or not to figure out that it is a subselect and then pass another flag
subselect to the getForUdateClause method where we say
if(!forUpdate && !subselect)
forUpdateString.append(forReadOnlyClause)
to achieve this we would probably have to override the toSelect methods in
DB2Dictionary again unless there is a better way.
On 4/10/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
As long as any given enum instance that corresponds to a
theoretically-unique enum value has internally-consistent state, we
should be in good shape. IOW, if the enum constructors are called
appropriately or internal state is otherwise maintained, then things
should work out fine.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 10, 2007 4:56 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or
> create our own?
>
> It should be ok anyway in the same VM. Unfortunately I had
> conflicting messages
> on weather it's the name or the ordinal that is guaranteed to
> work across the
> VMs :(.
>
> -marina
>
> Patrick Linskey wrote:
> > Fascinating. Happily, as it turns out, we never compare these things
> > directly; instead, we extract a value from the enums and
> use that. The
> > value is populated in the enum constructor:
> >
> > public enum IsolationLevel {
> > DEFAULT(-1),
> > NONE(Connection.TRANSACTION_NONE),
> > READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
> > READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
> > REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
> > SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
> >
> > private final int _connectionConstant;
> >
> > private IsolationLevel(int connectionConstant) {
> > _connectionConstant = connectionConstant;
> > }
> >
> > protected int getConnectionConstant() {
> > return _connectionConstant;
> > }
> > }
> >
> > Do you know if the getConnectionConstant() method would
> return the same
> > value for different instances of the "same" module?
> >
> > -Patrick
> >
>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by email
and then delete it.
RE: OPENJPA-182: reuse Connection constants or create our own?
As long as any given enum instance that corresponds to a
theoretically-unique enum value has internally-consistent state, we
should be in good shape. IOW, if the enum constructors are called
appropriately or internal state is otherwise maintained, then things
should work out fine.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 10, 2007 4:56 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or
> create our own?
>
> It should be ok anyway in the same VM. Unfortunately I had
> conflicting messages
> on weather it's the name or the ordinal that is guaranteed to
> work across the
> VMs :(.
>
> -marina
>
> Patrick Linskey wrote:
> > Fascinating. Happily, as it turns out, we never compare these things
> > directly; instead, we extract a value from the enums and
> use that. The
> > value is populated in the enum constructor:
> >
> > public enum IsolationLevel {
> > DEFAULT(-1),
> > NONE(Connection.TRANSACTION_NONE),
> > READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
> > READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
> > REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
> > SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
> >
> > private final int _connectionConstant;
> >
> > private IsolationLevel(int connectionConstant) {
> > _connectionConstant = connectionConstant;
> > }
> >
> > protected int getConnectionConstant() {
> > return _connectionConstant;
> > }
> > }
> >
> > Do you know if the getConnectionConstant() method would
> return the same
> > value for different instances of the "same" module?
> >
> > -Patrick
> >
>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
Re: OPENJPA-182: reuse Connection constants or create our own?
It should be ok anyway in the same VM. Unfortunately I had conflicting messages
on weather it's the name or the ordinal that is guaranteed to work across the
VMs :(.
-marina
Patrick Linskey wrote:
Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and use that. The
value is populated in the enum constructor:
public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
private final int _connectionConstant;
private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}
protected int getConnectionConstant() {
return _connectionConstant;
}
}
Do you know if the getConnectionConstant() method would return the same
value for different instances of the "same" module?
-Patrick
RE: OPENJPA-182: reuse Connection constants or create our own?
Fascinating. Happily, as it turns out, we never compare these things
directly; instead, we extract a value from the enums and use that. The
value is populated in the enum constructor:
public enum IsolationLevel {
DEFAULT(-1),
NONE(Connection.TRANSACTION_NONE),
READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
private final int _connectionConstant;
private IsolationLevel(int connectionConstant) {
_connectionConstant = connectionConstant;
}
protected int getConnectionConstant() {
return _connectionConstant;
}
}
Do you know if the getConnectionConstant() method would return the same
value for different instances of the "same" module?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 10, 2007 4:39 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: OPENJPA-182: reuse Connection constants or
> create our own?
>
> One note of caution about using enums - there can be a
> problem in passing enums
> from a client to a server using RMI-IIOP serialiazation - see
> GlassFish issue
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=193 for
> some details.
>
> regards,
> -marina
>
> Abe White wrote:
> >>I think that JDBCFetchPlan should take a Java 5 enum, and
> >>JDBCFetchConfiguration should use the Connection values.
> >
> >
> > Certainly JDBCFetchConfiguration should use the Connection
> values. I
> > personally have never had a problem with symbolic constants for
> > settings, but enums for the FetchPlan are cool too. So
> long as the
> > JPA QueryImpl parses the enum value and its string form correctly
> > when using it as a hint.
> >
> > Notice: This email message, together with any attachments,
> may contain information of BEA Systems, Inc., its
> subsidiaries and affiliated entities, that may be
> confidential, proprietary, copyrighted and/or legally
> privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not
> the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
Re: OPENJPA-182: reuse Connection constants or create our own?
One note of caution about using enums - there can be a problem in passing enums from a client to a server using RMI-IIOP serialiazation - see GlassFish issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=193 for some details. regards, -marina Abe White wrote: I think that JDBCFetchPlan should take a Java 5 enum, and JDBCFetchConfiguration should use the Connection values. Certainly JDBCFetchConfiguration should use the Connection values. I personally have never had a problem with symbolic constants for settings, but enums for the FetchPlan are cool too. So long as the JPA QueryImpl parses the enum value and its string form correctly when using it as a hint. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: OPENJPA-182: reuse Connection constants or create our own?
Implemented with r526316. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Abe White [mailto:[EMAIL PROTECTED] > Sent: Friday, April 06, 2007 2:17 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: OPENJPA-182: reuse Connection constants or > create our own? > > > > I think that JDBCFetchPlan should take a Java 5 enum, and > > JDBCFetchConfiguration should use the Connection values. > > Certainly JDBCFetchConfiguration should use the Connection > values. I > personally have never had a problem with symbolic constants for > settings, but enums for the FetchPlan are cool too. So long as the > JPA QueryImpl parses the enum value and its string form correctly > when using it as a hint. > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: OPENJPA-182: reuse Connection constants or create our own?
> I think that JDBCFetchPlan should take a Java 5 enum, and > JDBCFetchConfiguration should use the Connection values. Certainly JDBCFetchConfiguration should use the Connection values. I personally have never had a problem with symbolic constants for settings, but enums for the FetchPlan are cool too. So long as the JPA QueryImpl parses the enum value and its string form correctly when using it as a hint. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: OPENJPA-182: reuse Connection constants or create our own?
Adding in enum-based methods seems like a good idea to me. There isn't much harm in starting here and finishing the rest of FetchPlan later, so long as we do it someday. On 4/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: FYI, one problem with using an enum is that the rest of FetchPlan uses symbolic constants, not enums. But, I think that we should deprecate those methods and add in enum-based methods there when applicable at some point here, anyways. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Patrick Linskey > Sent: Friday, April 06, 2007 12:47 PM > To: open-jpa-dev@incubator.apache.org > Subject: OPENJPA-182: reuse Connection constants or create our own? > > Hi, > > There's one last open issue for OPENJPA-182 that I know of. Currently, > the JDBCFetchPlan.setIsolation() and > JDBCFetchConfiguration.setIsolation() methods use the > symbolic constants > defined in Connection. Should they, or should we use our own? > > I think that JDBCFetchPlan should take a Java 5 enum, and > JDBCFetchConfiguration should use the Connection values. The > reasons for > this are: > > 1. enums are nicer than symbolic constants, API-wise > > 2. enums should work more intuitively from XML-based hints or string > hints (we could make our hint conversion stuff know to try to > reflect on > enums based on their names) > > 3. Since these concepts are exactly the same as the Connection > constants, in JDBCFetchConfiguration, we should just use them and not > redefine the wheel. > > Thoughts? > > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > > __ > _ > Notice: This email message, together with any attachments, > may contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, > copyrighted and/or > legally privileged, and is intended solely for the use of the > individual > or entity named in this message. If you are not the intended > recipient, > and have received this message in error, please immediately > return this > by email and then delete it. > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -- -Michael Dick
RE: OPENJPA-182: reuse Connection constants or create our own?
FYI, one problem with using an enum is that the rest of FetchPlan uses symbolic constants, not enums. But, I think that we should deprecate those methods and add in enum-based methods there when applicable at some point here, anyways. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Patrick Linskey > Sent: Friday, April 06, 2007 12:47 PM > To: open-jpa-dev@incubator.apache.org > Subject: OPENJPA-182: reuse Connection constants or create our own? > > Hi, > > There's one last open issue for OPENJPA-182 that I know of. Currently, > the JDBCFetchPlan.setIsolation() and > JDBCFetchConfiguration.setIsolation() methods use the > symbolic constants > defined in Connection. Should they, or should we use our own? > > I think that JDBCFetchPlan should take a Java 5 enum, and > JDBCFetchConfiguration should use the Connection values. The > reasons for > this are: > > 1. enums are nicer than symbolic constants, API-wise > > 2. enums should work more intuitively from XML-based hints or string > hints (we could make our hint conversion stuff know to try to > reflect on > enums based on their names) > > 3. Since these concepts are exactly the same as the Connection > constants, in JDBCFetchConfiguration, we should just use them and not > redefine the wheel. > > Thoughts? > > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > > __ > _ > Notice: This email message, together with any attachments, > may contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, > copyrighted and/or > legally privileged, and is intended solely for the use of the > individual > or entity named in this message. If you are not the intended > recipient, > and have received this message in error, please immediately > return this > by email and then delete it. > > Notice: This email message, together with any attachments, > may contain information of BEA Systems, Inc., its > subsidiaries and affiliated entities, that may be > confidential, proprietary, copyrighted and/or legally > privileged, and is intended solely for the use of the > individual or entity named in this message. If you are not > the intended recipient, and have received this message in > error, please immediately return this by email and then delete it. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
OPENJPA-182: reuse Connection constants or create our own?
Hi, There's one last open issue for OPENJPA-182 that I know of. Currently, the JDBCFetchPlan.setIsolation() and JDBCFetchConfiguration.setIsolation() methods use the symbolic constants defined in Connection. Should they, or should we use our own? I think that JDBCFetchPlan should take a Java 5 enum, and JDBCFetchConfiguration should use the Connection values. The reasons for this are: 1. enums are nicer than symbolic constants, API-wise 2. enums should work more intuitively from XML-based hints or string hints (we could make our hint conversion stuff know to try to reflect on enums based on their names) 3. Since these concepts are exactly the same as the Connection constants, in JDBCFetchConfiguration, we should just use them and not redefine the wheel. Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
