openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-599) Postgres table cleanup problem
Date Mon, 29 Sep 2008 21:04:44 GMT

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

Kevin Sutter commented on OPENJPA-599:
--------------------------------------

Ignacio,
Thanks for taking the time to provide a patch for this issue.  I reviewed your proposed patch
for this issue.  Although I know very little about the Postgres database, I have a few comments
on the patch (no particular order).

o  I hesitate to make updates to the DBDictionary method signatures.  If anybody else has
extended our DBDictionary support, then they would immediately be broken when moving to whatever
release contains this change (if they have extended the implementation of this particular
method).  Instead, I prefer adding a new method with the new parameter(s) and having the old
method calling the new method with null'd out parameters.

o  I also hesitate to introduce new code in the Postgres dictionary that is exactly like the
code in DBDictionary, except for one minor change.  If the logic in DBDictionary changes for
whatever reason, the corresponding methods in the other dictionaries may or may not be noticed.
 Could the change be re-factored to allow the majority of the logic in DBDictionary to be
used, except for the special case code needed for Postgres?  What about introducing a new
protected method in DBDictionary that would have an empty implementation in DBDictionary,
but could be overridden in the Postgres Dictionary?  Or, something to that effect.

o  FYI, if we do re-factor the method signatures, I would always add the new parameters to
the end of the existing parameter list.  This allows for the mechanism I outlined in the first
bullet with nulling out the "missing" parameters.  Not sure, but this additional parameter
method mechanism may also help with not rippling a change through out the code base.

o  The issue mentions that this patch should be committed to 1.2.x, but now that trunk is
1.3.0, I would assume that's where you would like the change to go.

o  If you could take a look at doing this re-factoring to limit the potential exposure to
other dictionaries and other users, then we can probably go ahead with the contribution. 
Or, convince me that this re-factoring is not necessary...  :-)

Thanks,
Kevin


> Postgres table cleanup problem
> ------------------------------
>
>                 Key: OPENJPA-599
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-599
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 1.1.0
>            Reporter: Ignacio Andreu
>            Assignee: Ignacio Andreu
>         Attachments: OPENJPA-599.patch
>
>
> In the Stream support OpenJPA uses a system table (pg_largepbject) at the end of the
test cases OpenJPA doesn't delete the records generated by the test.
> The delete operation isn't trivial, because other programs in other databases can use
this table, we've to delete only the records that we've inserted.

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


Mime
View raw message