[
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.
