Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <362380103.1209336055664.JavaMail.jira@brutus>
Date: Sun, 27 Apr 2008 15:40:55 -0700 (PDT)
From: "Patrick Linskey (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-477) making StoreManager more flexible
 and extensible.
In-Reply-To: <507928.1199494233834.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592687#action_12592687 ] 

Patrick Linskey commented on OPENJPA-477:
-----------------------------------------

> What about making org.openjpa.kernel.exp expressions public? It could be convenient for
> developer's ExpressionFactories or ExpressionVisitors to identify the expressions being
> processed, or subclassing them. 

The challenges with making them public are:

1. currently, they do actual real work -- i.e., they dig into the object model to perform in-memory query parsing. This work is probably not desirable in most implementations. Overriding the appropriate methods might do the trick, but is dangerous; extenders would need to take care to override everything necessary.

2. making them extensible would potentially make it that much more painful if we changed anything there. Basically, that would make those classes into part of the implicit SPI in OpenJPA.

3. making them public would potentially encourage developing an inefficient query processing engine, in which OpenJPA generated the AST and then the back-end walked that AST. By encouraging back-end developers to put together their own implementations of the interfaces, I expect that it's more likely that the implementations will eliminate one graph traversal more regularly. Of course, providing an invisible hand to encourage "good design" is not really our business, so this is a secondary concern.

I think it would be useful to move all those classes into a new 'inmem' package to get them out of the way and reduce clutter in that package, though.

> making StoreManager more flexible and extensible.
> -------------------------------------------------
>
>                 Key: OPENJPA-477
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-477
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 1.0.2
>            Reporter: Daniel Lee
>             Fix For: 1.1.0
>
>         Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.613332.patch
>
>
> The OpenJPA StoreManager needs some modifications to make it more flexible and extensible.  For example, some private methods and attributes need to made either public or protected.  The attached patch identifies the areas that have been identified thus far.  Please let me know if there are any concerns.  Many thanks in advance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.