You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Daniel Lee (JIRA)" <ji...@apache.org> on 2008/01/05 01:50:33 UTC
[jira] Created: (OPENJPA-477) making StoreManager more flexible and
extensible.
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.0.2, 1.1.0
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.
RE: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by Pinaki Poddar <pp...@bea.com>.
Thanks, Kevin. You put it in clearer words.
"The limits of your language are the limits of your world." - Ludwig
Wittgenstein
-----Original Message-----
From: Kevin Sutter [mailto:kwsutter@gmail.com]
Sent: Wednesday, January 09, 2008 2:49 PM
To: dev@openjpa.apache.org
Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more
flexible and extensible.
That's a fair point, Pinaki. That is, don't make a lot of these "code
relaxations" until we're sure that they are needed. Don't get carried
away. Make them as needed. Don't make them just because we think we
need them. That way, we can be clearer on the intent of the changes as
we commit them. Makes sense.
Kevin
On Jan 9, 2008 1:41 PM, Pinaki Poddar <pp...@bea.com> wrote:
> Hello Daniel,
> Relax access restrictions on JDBCStoreManager or whichever parts you
> deem necessary to support non-JDBC based access to DB2. My only
> suggestion is do it by-parts, isothermally, on-demand, as "More detail
> information can be provided once it becomes available" becomes true.
> My concern is, otherwise, this patch may set a precedence of
> large-scale, anticipatory changes without specific use cases
scenarios.
>
>
>
> -----Original Message-----
> From: Daniel Lee [mailto:tsunfanglee@gmail.com]
> Sent: Wednesday, January 09, 2008 1:05 PM
> To: dev@openjpa.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more
> flexible and extensible.
>
> Right, IBM has an alternate interface (other than JDBC) to access DB2.
> In order to use OpenJPA thru that interface in a project, we need to
> sub-class JDBC StoreManager. More detail information can be provided
> once it becomes available. Thanks.
>
> On 1/8/08, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
> >
> >
> > [
> > https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian
> > .j
> > ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1
> > 25
> > 56965#action_12556965]
> >
> > Pinaki Poddar commented on OPENJPA-477:
> > ---------------------------------------
> >
> > "a recent practice for providing a proprietary extension to use an
> > interface other than JDBC" - elaboration on this extension will help
> > everyone to appreciate the reasons for this patch better --
> > especially
>
> > when the changes required by this extension is not only confined at
> > StoreManager but permeates to almost every tier of OpenJPA
> > (StateManager, Broker, Configuration...).
> >
> >
> >
> > > 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.0.2, 1.1.0
> > >
> > > Attachments: OPENJPA-477.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.
> >
> >
>
> 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: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by Kevin Sutter <kw...@gmail.com>.
That's a fair point, Pinaki. That is, don't make a lot of these "code
relaxations" until we're sure that they are needed. Don't get carried
away. Make them as needed. Don't make them just because we think we need
them. That way, we can be clearer on the intent of the changes as we commit
them. Makes sense.
Kevin
On Jan 9, 2008 1:41 PM, Pinaki Poddar <pp...@bea.com> wrote:
> Hello Daniel,
> Relax access restrictions on JDBCStoreManager or whichever parts you
> deem necessary to support non-JDBC based access to DB2. My only
> suggestion is do it by-parts, isothermally, on-demand, as "More detail
> information can be provided once it becomes available" becomes true.
> My concern is, otherwise, this patch may set a precedence of
> large-scale, anticipatory changes without specific use cases scenarios.
>
>
>
> -----Original Message-----
> From: Daniel Lee [mailto:tsunfanglee@gmail.com]
> Sent: Wednesday, January 09, 2008 1:05 PM
> To: dev@openjpa.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more
> flexible and extensible.
>
> Right, IBM has an alternate interface (other than JDBC) to access DB2.
> In order to use OpenJPA thru that interface in a project, we need to
> sub-class JDBC StoreManager. More detail information can be provided
> once it becomes available. Thanks.
>
> On 1/8/08, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
> >
> >
> > [
> > https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.j
> > ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=125
> > 56965#action_12556965]
> >
> > Pinaki Poddar commented on OPENJPA-477:
> > ---------------------------------------
> >
> > "a recent practice for providing a proprietary extension to use an
> > interface other than JDBC" - elaboration on this extension will help
> > everyone to appreciate the reasons for this patch better -- especially
>
> > when the changes required by this extension is not only confined at
> > StoreManager but permeates to almost every tier of OpenJPA
> > (StateManager, Broker, Configuration...).
> >
> >
> >
> > > 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.0.2, 1.1.0
> > >
> > > Attachments: OPENJPA-477.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.
> >
> >
>
> 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: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by Pinaki Poddar <pp...@bea.com>.
Hello Daniel,
Relax access restrictions on JDBCStoreManager or whichever parts you
deem necessary to support non-JDBC based access to DB2. My only
suggestion is do it by-parts, isothermally, on-demand, as "More detail
information can be provided once it becomes available" becomes true.
My concern is, otherwise, this patch may set a precedence of
large-scale, anticipatory changes without specific use cases scenarios.
-----Original Message-----
From: Daniel Lee [mailto:tsunfanglee@gmail.com]
Sent: Wednesday, January 09, 2008 1:05 PM
To: dev@openjpa.apache.org
Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more
flexible and extensible.
Right, IBM has an alternate interface (other than JDBC) to access DB2.
In order to use OpenJPA thru that interface in a project, we need to
sub-class JDBC StoreManager. More detail information can be provided
once it becomes available. Thanks.
On 1/8/08, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.j
> ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=125
> 56965#action_12556965]
>
> Pinaki Poddar commented on OPENJPA-477:
> ---------------------------------------
>
> "a recent practice for providing a proprietary extension to use an
> interface other than JDBC" - elaboration on this extension will help
> everyone to appreciate the reasons for this patch better -- especially
> when the changes required by this extension is not only confined at
> StoreManager but permeates to almost every tier of OpenJPA
> (StateManager, Broker, Configuration...).
>
>
>
> > 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.0.2, 1.1.0
> >
> > Attachments: OPENJPA-477.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.
>
>
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: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by Daniel Lee <ts...@gmail.com>.
Right, IBM has an alternate interface (other than JDBC) to access DB2. In
order to use OpenJPA thru that interface in a project, we need to sub-class
JDBC StoreManager. More detail information can be provided once it becomes
available. Thanks.
On 1/8/08, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556965#action_12556965]
>
> Pinaki Poddar commented on OPENJPA-477:
> ---------------------------------------
>
> "a recent practice for providing a proprietary extension to use an
> interface other than JDBC" - elaboration on this extension will help
> everyone to appreciate the reasons for this patch better -- especially when
> the changes required by this extension is not only confined at StoreManager
> but permeates to almost every tier of OpenJPA (StateManager, Broker,
> Configuration...).
>
>
>
> > 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.0.2, 1.1.0
> >
> > Attachments: OPENJPA-477.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.
>
>
Re: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by catalina wei <ca...@gmail.com>.
Hi Patrick,
We are still working on making JDBC LRS support extensible.
If you think this issue should be marked as resolved, we could open another
JIRA issue for the LRS extensibility.
Catalina
On 4/27/08, Patrick Linskey (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592688#action_12592688]
>
> Patrick Linskey commented on OPENJPA-477:
> -----------------------------------------
>
> Can this issue be marked as resolved?
>
> > 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.
>
>
Re: [jira] Updated: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by catalina wei <ca...@gmail.com>.
Hi,
Are there any comments on the second patch that Daniel put out last
Wednesday (01/16/08) ?
We would like to commit this patch if there is no other comments by the end
of 01/22.
Catalina Wei
On Jan 16, 2008 11:24 PM, Daniel Lee (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Daniel Lee updated OPENJPA-477:
> -------------------------------
>
> Attachment: OPENJPA-477-trunk612523.patch
>
> A new patch (OPENJPA-477-trunk612523.patch) is attached. The change of
> this patch is much simpler and the scope of it is much smaller than the
> previous one. Instead of making existing private methods protected, it
> extends only the portion that's required for the extensibility to
> JDBCStoreManager to interface with IBM SQLJ, etc with DB2.
>
> > 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.0.2, 1.1.0
> >
> > Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.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.
>
>
Re: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by catalina wei <ca...@gmail.com>.
Hi Pinaki,
Thanks for your comments.
We will add JavaDoc to newly introduced protected methods.
We don't need the patch to ProductDerivations, so there will be no change to
ProductDerivations.
A new patch will be attached to OPENJPA-477 as soon as we have the JavaDoc
added.
Catalina
On Jan 21, 2008 12:52 PM, Pinaki Poddar <pp...@bea.com> wrote:
> Hi,
> 1. the new changes are more compact.
> 2. newly introduced protected methods will benefit from some JavaDoc
> documentaion as their primary purpose is someone extending them.
> 3. The motivation for changes in configuration/Product derivations is
> not obvious. What is the plug-in point for this SQLJ extension in the
> object management layer: at EMF or at BrokerFactory?
>
> -----Original Message-----
> From: catalina wei [mailto:catalina.wei@gmail.com]
> Sent: Monday, January 21, 2008 2:29 PM
> To: dev@openjpa.apache.org
> Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more
> flexible and extensible.
>
> Hi Pinaki,
> You must be looking at the older patch, could you please take a look at
> the latest attached patch: OPENJPA-477-trunk612523.patch
>
> This patch should not have any "private" field to protected field
> changes.
>
> Thanks
>
> Catalina
>
> On Jan 21, 2008 12:08 PM, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
>
> >
> > [
> > https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.j
> > ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=125
> > 61111#action_12561111]
> >
> > Pinaki Poddar commented on OPENJPA-477:
> > ---------------------------------------
> >
> > 1. Some changes are making a private instance variables protected. A
> > better pattern will be to retain the variables as private and add
> > corresponding getter. That way the base class can exert more control
> > in the getter (for example, providing an unmodifiable copy in some
> > cases) especially when changing the the instance variable below the
> > hood can have adverse impact on the base class.
> >
> > 2. Some changes are redundant. For example, in JDBCStoreManager
> >
> > - private void connect(boolean ref) {
> > + protected void connect(boolean ref) {
> >
> > This class already provides for such extension. See the following the
>
> > same class
> > /**
> > * Connect to the database. This method is separated out so that it
> > * can be overridden.
> > */
> > protected RefCountConnection connectInternal() throws SQLException
> {
> > return new RefCountConnection(_ds.getConnection());
> > }
> >
> > or this one in TableJDBCSeq
> > - private transient JDBCConfiguration _conf = null;
> > + protected transient JDBCConfiguration _conf = null;
> >
> > when this class already has
> > public JDBCConfiguration getConfiguration() {
> > return _conf;
> > }
> >
> >
> >
> >
> > > 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.0.2, 1.1.0
> > >
> > > Attachments: OPENJPA-477-trunk612523.patch,
> > > OPENJPA-477.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.
> >
> >
>
> 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: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by Pinaki Poddar <pp...@bea.com>.
Hi,
1. the new changes are more compact.
2. newly introduced protected methods will benefit from some JavaDoc
documentaion as their primary purpose is someone extending them.
3. The motivation for changes in configuration/Product derivations is
not obvious. What is the plug-in point for this SQLJ extension in the
object management layer: at EMF or at BrokerFactory?
-----Original Message-----
From: catalina wei [mailto:catalina.wei@gmail.com]
Sent: Monday, January 21, 2008 2:29 PM
To: dev@openjpa.apache.org
Subject: Re: [jira] Commented: (OPENJPA-477) making StoreManager more
flexible and extensible.
Hi Pinaki,
You must be looking at the older patch, could you please take a look at
the latest attached patch: OPENJPA-477-trunk612523.patch
This patch should not have any "private" field to protected field
changes.
Thanks
Catalina
On Jan 21, 2008 12:08 PM, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.j
> ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=125
> 61111#action_12561111]
>
> Pinaki Poddar commented on OPENJPA-477:
> ---------------------------------------
>
> 1. Some changes are making a private instance variables protected. A
> better pattern will be to retain the variables as private and add
> corresponding getter. That way the base class can exert more control
> in the getter (for example, providing an unmodifiable copy in some
> cases) especially when changing the the instance variable below the
> hood can have adverse impact on the base class.
>
> 2. Some changes are redundant. For example, in JDBCStoreManager
>
> - private void connect(boolean ref) {
> + protected void connect(boolean ref) {
>
> This class already provides for such extension. See the following the
> same class
> /**
> * Connect to the database. This method is separated out so that it
> * can be overridden.
> */
> protected RefCountConnection connectInternal() throws SQLException
{
> return new RefCountConnection(_ds.getConnection());
> }
>
> or this one in TableJDBCSeq
> - private transient JDBCConfiguration _conf = null;
> + protected transient JDBCConfiguration _conf = null;
>
> when this class already has
> public JDBCConfiguration getConfiguration() {
> return _conf;
> }
>
>
>
>
> > 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.0.2, 1.1.0
> >
> > Attachments: OPENJPA-477-trunk612523.patch,
> > OPENJPA-477.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.
>
>
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: [jira] Commented: (OPENJPA-477) making StoreManager more flexible and extensible.
Posted by catalina wei <ca...@gmail.com>.
Hi Pinaki,
You must be looking at the older patch, could you please take a look at the
latest attached patch: OPENJPA-477-trunk612523.patch
This patch should not have any "private" field to protected field changes.
Thanks
Catalina
On Jan 21, 2008 12:08 PM, Pinaki Poddar (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561111#action_12561111]
>
> Pinaki Poddar commented on OPENJPA-477:
> ---------------------------------------
>
> 1. Some changes are making a private instance variables protected. A
> better pattern will be to retain the variables as private and add
> corresponding getter. That way the base class can exert more control in the
> getter (for example, providing an unmodifiable copy in some cases)
> especially when changing the the instance variable below the hood can have
> adverse impact on the base class.
>
> 2. Some changes are redundant. For example, in JDBCStoreManager
>
> - private void connect(boolean ref) {
> + protected void connect(boolean ref) {
>
> This class already provides for such extension. See the following the
> same class
> /**
> * Connect to the database. This method is separated out so that it
> * can be overridden.
> */
> protected RefCountConnection connectInternal() throws SQLException {
> return new RefCountConnection(_ds.getConnection());
> }
>
> or this one in TableJDBCSeq
> - private transient JDBCConfiguration _conf = null;
> + protected transient JDBCConfiguration _conf = null;
>
> when this class already has
> public JDBCConfiguration getConfiguration() {
> return _conf;
> }
>
>
>
>
> > 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.0.2, 1.1.0
> >
> > Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.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.
>
>
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557448#action_12557448 ]
Patrick Linskey commented on OPENJPA-477:
-----------------------------------------
Some more comments:
- A number of the changes make private fields more-visible. At least some of these fields have accessors already; is there some reason why the accessors are not sufficient? More importantly, when making private fields more visible, it's important to do a careful analysis of what the impact of external mutation to those fields would be.
- Is there any reason why you've changed some strings in DB2Dictionary to be static final?
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Xavi Arias (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583655#action_12583655 ]
Xavi Arias 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.
Xavi
> 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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Catalina Wei updated OPENJPA-477:
---------------------------------
Attachment: (was: OPENJPA-477.patch)
> 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.0.2, 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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564141#action_12564141 ]
Patrick Linskey commented on OPENJPA-477:
-----------------------------------------
I still do not understand why BrokerImpl needed changes; could you explain the changes there in more detail? I'm concerned that if the BrokerImpl needs extension to detect whether or not an instance is a member of the current working set, then other things could get out of sync as well.
> 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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556965#action_12556965 ]
Pinaki Poddar commented on OPENJPA-477:
---------------------------------------
"a recent practice for providing a proprietary extension to use an interface other than JDBC" - elaboration on this extension will help everyone to appreciate the reasons for this patch better -- especially when the changes required by this extension is not only confined at StoreManager but permeates to almost every tier of OpenJPA (StateManager, Broker, Configuration...).
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477.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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-477:
------------------------------------
Fix Version/s: (was: 1.1.0)
> 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
> 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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564448#action_12564448 ]
Catalina Wei commented on OPENJPA-477:
--------------------------------------
Hi, Patrick,
1. answer to your question on the changes we made to BrokerImpl:
It's not that BrokerImpl needs an extension to detect whether these instances are members of the working set. Rather, it's the BrokerImpl extension that needs the ability to override this detection. This is a fine distinction. Our BrokerImpl extension is only used while performing some pre-generation of sql statements. It is not used during the actual openjpa runtime. We wanted to use the same general mechanism for pre-generating sql as we do during runtime. To accomplish this, we needed to extend BrokerImpl and provide some unique processing for the object ids. We were trying to isolate the amount of code that had to be overridden to accomplish this task. By introducing these two new protected methods (checkForDuplicateId and assignObjectId), we could limit the amount of code that needed to be overridden. We are open to other suggestions.
2. thank you for removing 1.0.2 from the target release list.
Catalina
> 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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Daniel Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Lee updated OPENJPA-477:
-------------------------------
Attachment: OPENJPA-477.patch
This patch is base on OpenJPA 1.1 vrevision 608157.
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556266#action_12556266 ]
Pinaki Poddar commented on OPENJPA-477:
---------------------------------------
Agree that StoreManager should relax its field/method access for easier extensibility as well as to reuse rich implementations of JDBCStoreManager. However, this relaxation should be taken place in a more on-demand basis driven by use cases. This observation is based on my recent experience in extending JDBCStoreManager
a) to transact on distributed databases as opposed to a single database
and b) adapt for XA-complaint data sources.
Both extensions required access relaxations of one private field and one method signatures. But the changes were localized, driven by specific use cases. Hence, I recommend that we change fields/methods from private to protected as and when a particular use case demands it rather than doing it across the board as this patch seems to suggest.
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Daniel Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556955#action_12556955 ]
Daniel Lee commented on OPENJPA-477:
------------------------------------
In fact, the patch is part of a recent practice for providing a proprietary extension to use an interface other than JDBC. The patch can apply to other interface easily but wasn't trying to relax StoreManager in general. Thanks.
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561111#action_12561111 ]
Pinaki Poddar commented on OPENJPA-477:
---------------------------------------
1. Some changes are making a private instance variables protected. A better pattern will be to retain the variables as private and add corresponding getter. That way the base class can exert more control in the getter (for example, providing an unmodifiable copy in some cases) especially when changing the the instance variable below the hood can have adverse impact on the base class.
2. Some changes are redundant. For example, in JDBCStoreManager
- private void connect(boolean ref) {
+ protected void connect(boolean ref) {
This class already provides for such extension. See the following the same class
/**
* Connect to the database. This method is separated out so that it
* can be overridden.
*/
protected RefCountConnection connectInternal() throws SQLException {
return new RefCountConnection(_ds.getConnection());
}
or this one in TableJDBCSeq
- private transient JDBCConfiguration _conf = null;
+ protected transient JDBCConfiguration _conf = null;
when this class already has
public JDBCConfiguration getConfiguration() {
return _conf;
}
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Daniel Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Lee updated OPENJPA-477:
-------------------------------
Attachment: OPENJPA-477-trunk612523.patch
A new patch (OPENJPA-477-trunk612523.patch) is attached. The change of this patch is much simpler and the scope of it is much smaller than the previous one. Instead of making existing private methods protected, it extends only the portion that's required for the extensibility to JDBCStoreManager to interface with IBM SQLJ, etc with DB2.
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-477:
------------------------------------
Fix Version/s: (was: 1.0.2)
As far as I can tell, this improvement is not in scope for the 1.0.2 branch; removing 1.0.2 from the target release list.
> 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.
[jira] Resolved: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick resolved OPENJPA-477.
----------------------------------
Resolution: Fixed
Marking as resolved per Patrick's comments on April 27th. Fay's patch for BatchingPreparedStatement can be evaluated under issue OPENJPA-589
> 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
> Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.613332.patch, openjpa.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Fay Wang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fay Wang updated OPENJPA-477:
-----------------------------
Attachment: openjpa.patch
The attached patch is to make BatchingPreparedStatementManagerImpl more flexible and extensible.
> 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
> Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.613332.patch, openjpa.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592688#action_12592688 ]
Patrick Linskey commented on OPENJPA-477:
-----------------------------------------
Can this issue be marked as resolved?
> 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.
[jira] Updated: (OPENJPA-477) making StoreManager more flexible and
extensible.
Posted by "Catalina Wei (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Catalina Wei updated OPENJPA-477:
---------------------------------
Attachment: OPENJPA-477.613332.patch
A revised patch OPENJPA-477.613332.patch is attached.
We would like to commit this patch to trunk.
Please provide your comments.
Thanks.
> 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.0.2, 1.1.0
>
> Attachments: OPENJPA-477-trunk612523.patch, OPENJPA-477.613332.patch, OPENJPA-477.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.
[jira] Commented: (OPENJPA-477) making StoreManager more flexible
and extensible.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564456#action_12564456 ]
Patrick Linskey commented on OPENJPA-477:
-----------------------------------------
That makes sense. Not having access to the code in question, I don't have much input about alternate approaches.
It was more the runtime behavior that I was interested in anyways.
Regarding the project as a whole: what are your plans for it, source-code-wise? It sounds like a lot of the work that you're doing could be reused for some of the SQL caching and manual-SQL-specification issues that have been bouncing around over the last months. I'd love to figure out some way to take advantage of the work you guys are doing to achieve some of these alternate goals.
> 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.