You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👍
ultimately we'd like to contribute this feature however as we're under a bit of time pressure we have started a workaround based on hacking 'slightly' the code which handles Collection
basically adding || type.isArray() to the accept method
and then intercepting the code viz.
if( obj instanceof Object[])
return type.cast(Array.asList(obj))
[we're not intending adding this 'hack' as a branch unless author approves - he is in favour of a branch for definitive solution for Arrays ( subclassing Differ , Accessor , etc..) ]
Ha, nice hack! Good to hear, that this works for you. Did you implement this solution based on the master branch or this one? Which classes did you modify exactly? Does it also work for merging?
The branch I'm currently working on (major-rewrite-1.0) adds a completely restructured API to allow the ObjectDiffer to be extended with custom differs. The goal is to make it really easy to experiment with solutions for currently unsupported features like diffing Arrays and merging Lists without the need to fork the project.
Although the new API isn't exactly stable yet, that would be the perfect place to start working on a definitive solution for Array support. Doing so would also serve as a nice field test for the extension API. I'd be happy to give you some pointers as soon as you are ready to start working on this.
Diarmuid and I worked on the major-rewrite-1.0 branch; we wanted to create a proper Array Differ but then, because of lack of time, we realized that we could "cheat" it converting the Array into a Collection. It worked fine so far; we didn't try the merge yet.
We were also looking at how extend the filtering/ignoring properties; we didn't spend too much time honestly looking at the code, but we could not figure out a proper way of adding nested properties to the ignore list (eg. the same property always ignored regardless the class or specifying the hierarchy).
We would really like to contribute to your library, extending it etc.
Do you have any hints about the ignoring properties?
The kind of filtering you mentioned was not yet supported. However, I thought it's a good idea, so I implemented it over the weekend. You can find an example on how to do it here. Hope that helps!
I have tried the latest changes but it seems not working for properties not in the root; perhaps I did something wrong but converting your groovy example into java did not get the expected results.
I'll double-check as soon as I get the chance. It would be useful to see your code, though. Or at least a simplified example that demonstrates the problem. Could you send me something like that?
I have tried the latest changes but it seems not working for properties not in the root; perhaps I did something wrong but converting your groovy example into java did not get the expected results.
Any hint?
Alex
—
Reply to this email directly or view it on GitHub.
I will double check myself and I would post a code snippet. My domain model is very complex.
It would be very useful to ignore properties by type and be also able to specify the class (not the instance) where the property to ignore/include is defined.
As I said I would like to contribute to the project and it would be handy if you could walk me through the design of your library (concepts such as instance, propery aware, differ, etc). It would speed up the fixing of bugs and the adding of new features.
awesome, that you want to contribute! I will try to write some kind of general vision and development guideline over the weekend. As a rule of thumb there are two things that are very important to me for this project: a) keep the public API as simple and unambiguous as possible and b) write unit and integration tests for everything.
In the meantime the changes in this commit should serve as a good reference to see how to implement functionality to ignore nodes.
Activity
SQiShER commentedon Sep 2, 2012
Is anyone actually +1-ing this or is this a phantom requirement?
gembin commentedon Sep 21, 2012
+1, i think it's basic requirement
ishomersimpson commentedon Sep 21, 2012
+1
diarmuidkeane commentedon Jan 30, 2014
👍
ultimately we'd like to contribute this feature however as we're under a bit of time pressure we have started a workaround based on hacking 'slightly' the code which handles Collection
basically adding || type.isArray() to the accept method
and then intercepting the code viz.
if( obj instanceof Object[])
return type.cast(Array.asList(obj))
[we're not intending adding this 'hack' as a branch unless author approves - he is in favour of a branch for definitive solution for Arrays ( subclassing Differ , Accessor , etc..) ]
SQiShER commentedon Jan 30, 2014
Ha, nice hack! Good to hear, that this works for you. Did you implement this solution based on the master branch or this one? Which classes did you modify exactly? Does it also work for merging?
The branch I'm currently working on (major-rewrite-1.0) adds a completely restructured API to allow the
ObjectDifferto be extended with custom differs. The goal is to make it really easy to experiment with solutions for currently unsupported features like diffingArraysand mergingListswithout the need to fork the project.Although the new API isn't exactly stable yet, that would be the perfect place to start working on a definitive solution for Array support. Doing so would also serve as a nice field test for the extension API. I'd be happy to give you some pointers as soon as you are ready to start working on this.
alexscal commentedon Jan 31, 2014
Hi Daniel,
Diarmuid and I worked on the major-rewrite-1.0 branch; we wanted to create a proper Array Differ but then, because of lack of time, we realized that we could "cheat" it converting the Array into a Collection. It worked fine so far; we didn't try the merge yet.
We were also looking at how extend the filtering/ignoring properties; we didn't spend too much time honestly looking at the code, but we could not figure out a proper way of adding nested properties to the ignore list (eg. the same property always ignored regardless the class or specifying the hierarchy).
We would really like to contribute to your library, extending it etc.
Do you have any hints about the ignoring properties?
Thanks.
Regards,
Alex
SQiShER commentedon Feb 2, 2014
Hi @alexscal & @diarmuidkeane,
The kind of filtering you mentioned was not yet supported. However, I thought it's a good idea, so I implemented it over the weekend. You can find an example on how to do it here. Hope that helps!
Cheers,
Daniel
alexscal commentedon Feb 5, 2014
hi Daniel,
thank you for your prompt reply.
I have tried the latest changes but it seems not working for properties not in the root; perhaps I did something wrong but converting your groovy example into java did not get the expected results.
Any hint?
Alex
SQiShER commentedon Feb 5, 2014
I'll double-check as soon as I get the chance. It would be useful to see your code, though. Or at least a simplified example that demonstrates the problem. Could you send me something like that?
alexscal commentedon Feb 5, 2014
hi Daniel,
I will double check myself and I would post a code snippet. My domain model is very complex.
It would be very useful to ignore properties by type and be also able to specify the class (not the instance) where the property to ignore/include is defined.
As I said I would like to contribute to the project and it would be handy if you could walk me through the design of your library (concepts such as instance, propery aware, differ, etc). It would speed up the fixing of bugs and the adding of new features.
Thank you.
Regards,
Alex
SQiShER commentedon Feb 6, 2014
Hi Alex,
awesome, that you want to contribute! I will try to write some kind of general vision and development guideline over the weekend. As a rule of thumb there are two things that are very important to me for this project: a) keep the public API as simple and unambiguous as possible and b) write unit and integration tests for everything.
In the meantime the changes in this commit should serve as a good reference to see how to implement functionality to ignore nodes.
Cheers,
Daniel
alexscal commentedon Feb 26, 2014
Hi Daniel,
I am just wondering, did you remove/hide the major-rewrite-1.0 branch?
Thanks.
Alex
SQiShER commentedon Feb 26, 2014
Hey, I merged it into the master.
ksafonov commentedon Jun 22, 2014
+1
SQiShER commentedon Sep 9, 2015
Important information regarding this issue can be found over here: #143