Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <13050911.97861284047854088.JavaMail.jira@thor>
Date: Thu, 9 Sep 2010 11:57:34 -0400 (EDT)
From: "Mark Lewis (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Issue Comment Edited: (BEANUTILS-304) BeanDiff -
 encapsulate, apply, and merge bean differences
In-Reply-To: <16060251.1202401448552.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/BEANUTILS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907665#action_12907665 ] 

Mark Lewis edited comment on BEANUTILS-304 at 9/9/10 11:56 AM:
---------------------------------------------------------------

If it did use annotations/interfaces, it would be an anomaly within Commons BeanUtils.  None of the current APIs require changes to your beans, and I'm sure that's by design.  (Also, I think they're still trying to make the library compatible with Java 1.4, so annotations may not be allowed.)

Some level of customization could be handled already with {{org.apache.commons.beanutils.Converter}} and {{java.util.Comparator}}.  As for sub-diff, I think that would best be handled programmatically rather than declaratively.  You'd run a diff on the two parent beans.  Then if the child beans are different, you could run a diff on them too.  This would simplify the API quite a bit, as we wouldn't have to worry about representing nested differences.

These are great use-cases, though, and we should consider all possibilities.

      was (Author: malfunction84):
    If it did use annotations/interfaces, it would be an anomaly within Commons BeanUtils.  None of the current APIs require changes to your beans, and I'm sure that's by design.  (Also, I think they're still trying to make the library compatible with Java 1.4, so annotations may not be allowed.)

Some level of customization could be handled already with {{org.apache.commons.beanutil.Converter}} and {{java.util.Comparator}}.  As for sub-diff, I think that would best be handled programmatically rather than declaratively.  You'd run a diff on the two parent beans.  Then if the child beans are different, you could run a diff on them too.  This would simplify the API quite a bit, as we wouldn't have to worry about representing nested differences.

These are great use-cases, though, and we should consider all possibilities.
  
> BeanDiff - encapsulate, apply, and merge bean differences
> ---------------------------------------------------------
>
>                 Key: BEANUTILS-304
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-304
>             Project: Commons BeanUtils
>          Issue Type: New Feature
>          Components: Bean / Property Utils, Bean-Collections, ConvertUtils & Converters, DynaBean
>    Affects Versions: LATER THAN 1.8.4
>            Reporter: Mark Lewis
>             Fix For: LATER THAN 1.8.4
>
>   Original Estimate: 240h
>  Remaining Estimate: 240h
>
> It would be great to have a way to compare two beans and capture the diff somehow.  This is just my initial brainstorm on the idea:
> - The BeanDiff class encapsulates differences between two beans -of the same type-, the source bean and the target bean.
> - A BeanDiff instance represents what property assignments would be necessary to turn the target bean into the source bean.
> - A BeanDiff can be applied to a target bean, performing the necessary property assignments to make its property values exactly match the source bean.
> - Two BeanDiff instances can be merged into a single BeanDiff instance, allowing multiple source beans to be merged into one target bean.
> - If a conflict would occur during a merge (from a property being assigned two different values), a BeanDiffConflictException is thrown.
> - The BeanDiffConflictException contains an array of BeanDiffConflict objects.
> - Each BeanDiffConflict instance represents a single property and the two conflicting values that were to be assigned.
> - All these actions would work on DynaBeans as well.
> - +Converters would be able to account for type differences in source and target bean properties.+
> An example of how this could be used is when dealing with ORM and optimistic locking.  Knowing exactly which properties have been modified would allow concurrent modification of a bean (record) without fear of reasserting the original values and destroying someone else's changes.

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