David D., No! You just need to copy the DTO. Let the client do whatever it wants with the DTO; it won’t mess up the system. If the client is “stupid” enough to change the value of the DTO, then that’s the client’s problem.
There is no more worry about immutability / value object. There are only copies of objects. BTW, that is why I suggested that we add a copy() method. It does take a change of mindset. I also came from the School of Immutable Objects. But copying objects works, too. Cheers, =David > On Aug 18, 2016, at 9:16 PM, David Daniel <[email protected]> wrote: > > So for the article above what I am struggling with is how to do > immutability/mutability with the DTO spec. With java beans there is a get > and set method for each attribute. If DTO's had this the way I would do it > is as follows. I would have an attribute for mutability that is either > true or false. If false I would put an aspect around the get function that > returns a clone of the attribute value. I would put an aspect around the > set function that throws an exception. For mutable DTO's my converter > would delegate deserialization to a CRDT service that would put aspects > around set that watches for changes and aspects around get/set that throws > an exception if called when the DTO is in a conflicted state. The CRDT > service would then return the DTO to the converter. On update it modifies > the CRDT structure as above. In the converter if the DTO is watched then > when serializing it delegate serialization to the CRDT service. I am not > sure how to model immutability with the current DTO standard because there > are no get or set functions that I can put aspects around. > > On Thu, Aug 18, 2016 at 6:40 AM, David Daniel <[email protected]> > wrote: > >> For me helps by having the schema that allows for something some other >> service uses to do the automatic merging using the tools available in >> dosgi, but I understand that nothing can be really automatic because it can >> require merges and there is garbage collection that will need to happen on >> the objects during reconciliation. If the DTO's are just public fields >> they do not offer anything over using a pojo. Where they start to be >> useful to me is by defining in a standard way how the data can be turned >> into an object. Examples would be a way to define a key so that indexes >> and equality can be determined, or defining relationships between sub >> objects so when doing a deep clone the user can decide how many links to >> traverse. Scoping rules could also be defined so the converter has >> information that could be used in determining which type of object to >> serialize to in different situations. The standard can choose not to >> define these things and let the application decide in order to be more >> flexible or it can try to define some of these things in order to make >> services or tools around DTO's more standardized. I think I am trying to >> follow what schema elements will be in DTO's and make sure that I take >> advantage of them rather than writing my own. As of right now that I am >> just using them as pojo's though so I don't have any feelings or advice on >> the way to go and what types of schema things I would be able to take >> advantage of. >> >> On Thu, Aug 18, 2016 at 4:23 AM, David Bosschaert < >> [email protected]> wrote: >> >>> Hi Davids, >>> >>> What is it exactly from that article that you think would make sense in >>> the >>> context of OSGi? The automatic merging of concurrent data updates? >>> >>> Thanks, >>> >>> David >>> >>> On 18 August 2016 at 07:50, David Leangen <[email protected]> wrote: >>> >>>> >>>> That is interesting, indeed! I only quickly skimmed through the article, >>>> but it does indeed appear to be a potentially interesting property for >>>> dosgi. >>>> >>>> If I believe what the authors write in the abstract, it provides a >>>> relatively simple and deterministic method that could be implemented in >>>> code. >>>> >>>> Cheers, >>>> =David >>>> >>>> >>>>> On Aug 17, 2016, at 10:21 PM, David Daniel < >>> [email protected]> >>>> wrote: >>>>> >>>>> read an interesting article this morning >>> http://arxiv.org/abs/1608.03960 >>>>> Something like this would be an interesting property to have for dosgi >>>>> which is one of the use cases for DTO's >>>>> >>>>> On Wed, Aug 17, 2016 at 6:47 AM, David Leangen (JIRA) < >>> [email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> [ https://issues.apache.org/jira/browse/FELIX-5325?page= >>>>>> com.atlassian.jira.plugin.system.issuetabpanels:comment- >>>>>> tabpanel&focusedCommentId=15424288#comment-15424288 ] >>>>>> >>>>>> David Leangen commented on FELIX-5325: >>>>>> -------------------------------------- >>>>>> >>>>>> Awesome. Thank you! :-) >>>>>> >>>>>>> Patch for embedded DTO (in DTO) >>>>>>> ------------------------------- >>>>>>> >>>>>>> Key: FELIX-5325 >>>>>>> URL: https://issues.apache.org/jira >>> /browse/FELIX-5325 >>>>>>> Project: Felix >>>>>>> Issue Type: Improvement >>>>>>> Components: Converter >>>>>>> Reporter: David Leangen >>>>>>> Assignee: David Bosschaert >>>>>>> Priority: Minor >>>>>>> Attachments: patch.diff >>>>>>> >>>>>>> >>>>>>> This patch adds support for converting a DTO that contains an >>> embedded >>>>>> DTO. It uses recursive calls to Converter.convert() to accomplish >>> this. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> This message was sent by Atlassian JIRA >>>>>> (v6.3.4#6332) >>>>>> >>>> >>>> >>> >> >>
