Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
MIME-Version: 1.0
In-Reply-To: <7BB0FB20-C9C2-4EEF-819C-12EDCC2F395C@leangen.net>
References: <CAMit8SrNe0x9Jx_ecZByPrPf20OPh78K_VdOPEr-3a4j_1Co+g@mail.gmail.com>
 <CAP+1itO-Hx=VaLrpjPeNAdYXuZmAd_pzvsAucaYOAXq1cdhxhA@mail.gmail.com>
 <CAP+1itPdMDLWnX49oLXrO4xhgv3r2sYogutSRxBkPPWxtMmqRA@mail.gmail.com> <7BB0FB20-C9C2-4EEF-819C-12EDCC2F395C@leangen.net>
From: David Daniel <david.daniel.1979@gmail.com>
Date: Thu, 18 Aug 2016 08:50:43 -0400
Message-ID: <CAP+1itOiMxf+cLEFtY6TdFQbsZ-gqC47G9q9avApHzZ-ph0YLg@mail.gmail.com>
Subject: Re: [jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
To: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=001a114aae5eb00f89053a58079f
archived-at: Thu, 18 Aug 2016 12:50:51 -0000

--001a114aae5eb00f89053a58079f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So copy could work for immutability but it limits my ability to help the
client (which is normally me and I am definitely stupid enough to not think
about how I designed the system) but it doesn't help with how to add
mutability of data objects transferred between services.  I do think I may
be trying to do too much with DTO's but I am still trying to wrap my head
around where they should be used.  Do I just use them as pojo's that come
in and out of services and then immediately convert them to domain specific
objects or do I let them stick around and try and make use of them.

On Thu, Aug 18, 2016 at 8:26 AM, David Leangen <osgi@leangen.net> wrote:

>
> David D.,
>
> No! You just need to copy the DTO. Let the client do whatever it wants
> with the DTO; it won=E2=80=99t mess up the system. If the client is =E2=
=80=9Cstupid=E2=80=9D enough
> to change the value of the DTO, then that=E2=80=99s the client=E2=80=99s =
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 Immutabl=
e
> Objects. But copying objects works, too.
>
>
> Cheers,
> =3DDavid
>
>
>
> > On Aug 18, 2016, at 9:16 PM, David Daniel <david.daniel.1979@gmail.com>
> 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 d=
o
> 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 t=
he
> > 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 th=
en
> > when serializing it delegate serialization to the CRDT service.  I am n=
ot
> > 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 <
> david.daniel.1979@gmail.com>
> > 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 i=
t
> can
> >> require merges and there is garbage collection that will need to happe=
n
> on
> >> the objects during reconciliation.  If the DTO's are just public field=
s
> >> 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 turn=
ed
> >> into an object.  Examples would be a way to define a key so that index=
es
> >> 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 advic=
e
> 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 <
> >> david.bosschaert@gmail.com> 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 <osgi@leangen.net> wrote:
> >>>
> >>>>
> >>>> That is interesting, indeed! I only quickly skimmed through the
> article,
> >>>> but it does indeed appear to be a potentially interesting property f=
or
> >>>> 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,
> >>>> =3DDavid
> >>>>
> >>>>
> >>>>> On Aug 17, 2016, at 10:21 PM, David Daniel <
> >>> david.daniel.1979@gmail.com>
> >>>> 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) <
> >>> jira@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>   [ https://issues.apache.org/jira/browse/FELIX-5325?page=3D
> >>>>>> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> >>>>>> tabpanel&focusedCommentId=3D15424288#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)
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>

--001a114aae5eb00f89053a58079f--