Re: JPQL extensions

[Craig L Russell]

Hi,




I like allow, warn, and error (even though error isn't a verb).



Craig

On Jan 16, 2008, at 11:27 AM, Albert Lee wrote:

I don't like the ignore option. You get the wrong answer but we don't tell you? No, thanks. We also need to carefully read the JPA TCK compatibility rules. "Extensions" that the specification *requires* to throw an error are problematic.

After some thought, I think it would be more intuitive to use
[allow|warn|error], where:

if extension is specified,

allow = it will be honored,
warning = it will be processed but post a warning message and
error = an exception will be thrown.


extension will be tolerated


be thrown.

Albert Lee.

On Jan 16, 2008 11:11 AM, Pinaki Poddar <[EMAIL PROTECTED]> wrote:

ignore can also be a option as a toleration mode, that is application with ignore = extension is NOT honored but no warning message or exception will

Liked this one better
openjpa.extensions.JPQL = [true|false|warn]

On 'ignore' option I was thinking of a choice where the runtime
continues working when extended JPQL is used but ignores all the
extended clasues. On second thought though that does not look good to
me.

Instead of 'All' how about?
openjpa.extensions.* = [true|false|warn]


some features are more likely to remain exclusive to OpenJPA so the
property will reatin its significance.


-----Original Message-----
From: Albert Lee [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 10:35 AM
To: dev@openjpa.apache.org
Subject: Re: JPQL extensions


added in the future? How about

openjpa.extensions.All=[true|false|warn]
openjpa.extensions.JPQL=[true|false|warn]
openjpa.extensions.Xxxxxx=[true|false|warn] <-- future extensions


the options get interpreted?

Albert Lee.

On Jan 16, 2008 1:27 AM, Patrick Linskey <[EMAIL PROTECTED]> wrote:

If some of the extensions become part of JPA spec in future, then still Is JPQL the ONLY spec extension we have in mind? Do we just want 'none' or 'all' option or allow more granular enable when more extensions are What about if an extension gets adopted in future JPA spec, then how are

How would 'ignore' and 'false' differ?

Also, your naming would presumably restrict the property to just JPQL. What about a broader toggle to control strict JPA compliance? It seems

like if someone wants strict compliance, they're going to want it
everywhere, not just in JPQL.

-Patrick

On Jan 15, 2008 8:05 PM, Pinaki Poddar <[EMAIL PROTECTED]> wrote:

openjpa.jpql.Extensions : true|false|ignore|warn


-----Original Message-----
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 10:03 PM
To: dev@openjpa.apache.org
Subject: JPQL extensions

Hi,

Earlier today, I modified the JPQL parser to allow some extensions

to JPQL. I expect that there is other non-standard extended behavior

(JPQL and otherwise) in OpenJPA. It seems like it might be desirable

to have a property that controls whether or not OpenJPA allows

extended behavior.

I was thinking that a property like so could be useful:

   openjpa.JPAExtensions: true | false | warn

Thoughts?

-Patrick

--
Patrick Linskey
202 669 5907

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.

--
Patrick Linskey
202 669 5907

--
Albert Lee.


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

--
Albert Lee.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature