You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/04/05 00:22:10 UTC
API or Query hints
I think any time we make a change to the external view of the project
we need to have a discussion first.
IMHO The JIRA process is pretty good for this kind of stuff. Someone
proposes a feature with non-standardized external behavior and writes
up what it should look like. Then we agree on the details and go for it.
On this particular issue, I can see valid reasons for having an API
that modifies the behavior of the query, but also understand why it
might be good to mirror that behavior using query hints. But
whichever way we go, we need to agree on the name and semantics of
the API/property and how to pass it to the internal structures for
execution.
There is a danger in thinking of these as "hints". As I would like to
see it, the only down side to not recognizing a query hint is lower
performance. But if your application doesn't behave correctly if the
implementation can't do anything useful with the hint, then it's not
a hint but an application requirement. And if the hint can only be
executed in some specific databases, then we need to decide if we
throw an exception if the database isn't capable.
Craig
On Apr 4, 2007, at 2:17 PM, Abe White wrote:
>> ... for certain values of "our". I think that it's important that we
>> discuss API decisions as a group, as they have significant impacts on
>> the OpenJPA product moving forward. This is especially important when
>> there are dissenting views on a particular API decision, as is the
>> case
>> here.
>
> I agree with Patrick. API decisions need to be better thought out.
> For example, even if we decide as a group to use hints in this case,
> the names of the hints are important. The current hint names you
> chose are inconsistent with other OpenJPA hints in naming style and
> capitalization.
>
>
> 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.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: API or Query hints
Posted by Patrick Linskey <pl...@bea.com>.
> Do we need this function in 0.9.7 or can it wait until 0.9.8?
I don't have a strong opinion either way. If we decide to hold it for
0.9.8, then I think that it's important for us to either remove the
current functionality, or make sure it's understood that the current API
is subject to change without backwards-compatibility.
-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: Michael Dick [mailto:michael.d.dick@gmail.com]
> Sent: Wednesday, April 04, 2007 6:50 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: API or Query hints
>
> Do we need this function in 0.9.7 or can it wait until 0.9.8?
>
> When we're dealing with external APIs we need to be very
> careful that we're
> doing the right thing. I think we need some time to come to a
> consensus on
> the correct approach and I'd rather not delay 0.9.7 in the
> meantime. Abe
> cleaned up the code I dropped for default schemas earlier today, so I
> believe this is the last outstanding issue with 0.9.7.
>
> FTR I'm not voting for or against either implementation - I
> just don't want
> to commit to one path until we can agree to one of them.
>
> If the consensus is that this function should be included in
> 0.9.7 then I'll
> withdraw my comment and wait.
>
> Other gratuitous opinions:
>
> +1 to using a JIRA or the mailing list to discuss external
> changes before
> committing.
>
> +1 to Abe's comment regarding hint naming conventions, we
> should try to stay
> consistent.
>
>
> On 4/4/07, Patrick Linskey <pl...@bea.com> wrote:
> >
> > Hi,
> >
> > In the interests of putting my money where my mouth is, I attached a
> > patch to the JIRA issue, and included a description of the
> patch in the
> > JIRA issue. Hopefully, this will help a) make the problem
> and different
> > solutions more concrete, and b) quell any concerns about
> > implementability of the approach that I outlined.
> >
> > -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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> > > Sent: Wednesday, April 04, 2007 3:22 PM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: API or Query hints
> > >
> > > I think any time we make a change to the external view of the
> > > project
> > > we need to have a discussion first.
> > >
> > > IMHO The JIRA process is pretty good for this kind of
> stuff. Someone
> > > proposes a feature with non-standardized external behavior
> > > and writes
> > > up what it should look like. Then we agree on the details and
> > > go for it.
> > >
> > > On this particular issue, I can see valid reasons for
> having an API
> > > that modifies the behavior of the query, but also
> understand why it
> > > might be good to mirror that behavior using query hints. But
> > > whichever way we go, we need to agree on the name and semantics of
> > > the API/property and how to pass it to the internal structures for
> > > execution.
> > >
> > > There is a danger in thinking of these as "hints". As I would
> > > like to
> > > see it, the only down side to not recognizing a query
> hint is lower
> > > performance. But if your application doesn't behave
> correctly if the
> > > implementation can't do anything useful with the hint,
> then it's not
> > > a hint but an application requirement. And if the hint can only be
> > > executed in some specific databases, then we need to decide if we
> > > throw an exception if the database isn't capable.
> > >
> > > Craig
> > >
> > > On Apr 4, 2007, at 2:17 PM, Abe White wrote:
> > >
> > > >> ... for certain values of "our". I think that it's
> > > important that we
> > > >> discuss API decisions as a group, as they have significant
> > > impacts on
> > > >> the OpenJPA product moving forward. This is especially
> > > important when
> > > >> there are dissenting views on a particular API
> decision, as is the
> > > >> case
> > > >> here.
> > > >
> > > > I agree with Patrick. API decisions need to be better
> thought out.
> > > > For example, even if we decide as a group to use hints
> in this case,
> > > > the names of the hints are important. The current hint
> names you
> > > > chose are inconsistent with other OpenJPA hints in
> naming style and
> > > > capitalization.
> > > >
> > > >
> > > > 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.
> > >
> > > Craig Russell
> > > Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> > > 408 276-5638 mailto:Craig.Russell@sun.com
> > > P.S. A good JDO? O, Gasp!
> > >
> > >
> >
> > 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
>
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: API or Query hints
Posted by Michael Dick <mi...@gmail.com>.
Do we need this function in 0.9.7 or can it wait until 0.9.8?
When we're dealing with external APIs we need to be very careful that we're
doing the right thing. I think we need some time to come to a consensus on
the correct approach and I'd rather not delay 0.9.7 in the meantime. Abe
cleaned up the code I dropped for default schemas earlier today, so I
believe this is the last outstanding issue with 0.9.7.
FTR I'm not voting for or against either implementation - I just don't want
to commit to one path until we can agree to one of them.
If the consensus is that this function should be included in 0.9.7 then I'll
withdraw my comment and wait.
Other gratuitous opinions:
+1 to using a JIRA or the mailing list to discuss external changes before
committing.
+1 to Abe's comment regarding hint naming conventions, we should try to stay
consistent.
On 4/4/07, Patrick Linskey <pl...@bea.com> wrote:
>
> Hi,
>
> In the interests of putting my money where my mouth is, I attached a
> patch to the JIRA issue, and included a description of the patch in the
> JIRA issue. Hopefully, this will help a) make the problem and different
> solutions more concrete, and b) quell any concerns about
> implementability of the approach that I outlined.
>
> -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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> > Sent: Wednesday, April 04, 2007 3:22 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: API or Query hints
> >
> > I think any time we make a change to the external view of the
> > project
> > we need to have a discussion first.
> >
> > IMHO The JIRA process is pretty good for this kind of stuff. Someone
> > proposes a feature with non-standardized external behavior
> > and writes
> > up what it should look like. Then we agree on the details and
> > go for it.
> >
> > On this particular issue, I can see valid reasons for having an API
> > that modifies the behavior of the query, but also understand why it
> > might be good to mirror that behavior using query hints. But
> > whichever way we go, we need to agree on the name and semantics of
> > the API/property and how to pass it to the internal structures for
> > execution.
> >
> > There is a danger in thinking of these as "hints". As I would
> > like to
> > see it, the only down side to not recognizing a query hint is lower
> > performance. But if your application doesn't behave correctly if the
> > implementation can't do anything useful with the hint, then it's not
> > a hint but an application requirement. And if the hint can only be
> > executed in some specific databases, then we need to decide if we
> > throw an exception if the database isn't capable.
> >
> > Craig
> >
> > On Apr 4, 2007, at 2:17 PM, Abe White wrote:
> >
> > >> ... for certain values of "our". I think that it's
> > important that we
> > >> discuss API decisions as a group, as they have significant
> > impacts on
> > >> the OpenJPA product moving forward. This is especially
> > important when
> > >> there are dissenting views on a particular API decision, as is the
> > >> case
> > >> here.
> > >
> > > I agree with Patrick. API decisions need to be better thought out.
> > > For example, even if we decide as a group to use hints in this case,
> > > the names of the hints are important. The current hint names you
> > > chose are inconsistent with other OpenJPA hints in naming style and
> > > capitalization.
> > >
> > >
> > > 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.
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> >
>
> 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: API or Query hints
Posted by Patrick Linskey <pl...@bea.com>.
Hi,
In the interests of putting my money where my mouth is, I attached a
patch to the JIRA issue, and included a description of the patch in the
JIRA issue. Hopefully, this will help a) make the problem and different
solutions more concrete, and b) quell any concerns about
implementability of the approach that I outlined.
-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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Wednesday, April 04, 2007 3:22 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: API or Query hints
>
> I think any time we make a change to the external view of the
> project
> we need to have a discussion first.
>
> IMHO The JIRA process is pretty good for this kind of stuff. Someone
> proposes a feature with non-standardized external behavior
> and writes
> up what it should look like. Then we agree on the details and
> go for it.
>
> On this particular issue, I can see valid reasons for having an API
> that modifies the behavior of the query, but also understand why it
> might be good to mirror that behavior using query hints. But
> whichever way we go, we need to agree on the name and semantics of
> the API/property and how to pass it to the internal structures for
> execution.
>
> There is a danger in thinking of these as "hints". As I would
> like to
> see it, the only down side to not recognizing a query hint is lower
> performance. But if your application doesn't behave correctly if the
> implementation can't do anything useful with the hint, then it's not
> a hint but an application requirement. And if the hint can only be
> executed in some specific databases, then we need to decide if we
> throw an exception if the database isn't capable.
>
> Craig
>
> On Apr 4, 2007, at 2:17 PM, Abe White wrote:
>
> >> ... for certain values of "our". I think that it's
> important that we
> >> discuss API decisions as a group, as they have significant
> impacts on
> >> the OpenJPA product moving forward. This is especially
> important when
> >> there are dissenting views on a particular API decision, as is the
> >> case
> >> here.
> >
> > I agree with Patrick. API decisions need to be better thought out.
> > For example, even if we decide as a group to use hints in this case,
> > the names of the hints are important. The current hint names you
> > chose are inconsistent with other OpenJPA hints in naming style and
> > capitalization.
> >
> >
> > 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.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
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.