Make UUID an Immutable type by default

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Make UUID an Immutable type by default

Geoff Groos
Hey guys,

We’re just about to go to version 1.0, so I’m running over every piece of tech-debt I can think of to make sure all my ducks are in a row, and I found this in our project file (an XML serialized model):

      <ProjectState.ImmutableMomento>
        <associatedRunId>b723fec2-50f9-45fa-9a41-fee8d022b544</associatedRunId>
        <!-- ... -->
      </ProjectState.ImmutableMomento>
      <ProjectState.ImmutableMomento>
        <associatedRunId reference="../../ProjectState.ImmutableMomento/associatedRunId"/>

I cant think of a good reason for a UUID not to be immutable by default. Doing oneID == anotherID has to be as taboo as aString == anotherString to anybody whose willing to use a UUID object, meaning I don't think there’s any reason to preserve reference equality in serialization.

-Geoff

Reply | Threaded
Open this post in threaded view
|

Re: Make UUID an Immutable type by default

Jörg Schaible-2
Hi Geoff,

Geoff Groos wrote:

> Hey guys,
>
> We’re just about to go to version 1.0, so I’m running over every piece of
> tech-debt I can think of to make sure all my ducks are in a row, and I
> found this in our project file (an XML serialized model):
>
>       <ProjectState.ImmutableMomento>
>         <associatedRunId>b723fec2-50f9-45fa-9a41-
fee8d022b544</associatedRunId>

>         <!-- ... -->
>       </ProjectState.ImmutableMomento>
>       <ProjectState.ImmutableMomento>
>         <associatedRunId
>         reference="../../ProjectState.ImmutableMomento/associatedRunId"/>
>
> I cant think of a good reason for a UUID not to be immutable by default.
> Doing oneID == anotherID has to be as taboo as aString == anotherString to
> anybody whose willing to use a UUID object, meaning I don't think there’s
> any reason to preserve reference equality in serialization.

You're absolutely right. Can you open a JIRA ticket to track the issue,
please? Simply follow instructions at
http://xstream.codehaus.org/issues.html

Cheers,
Jörg

Sad to say, but 2 hours earlier, and it would already have been part of the
new release :-/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Make UUID an Immutable type by default

Geoff Groos
Thanks Jörg,
 
I created an account but have run into some http:500s and what-not from jira while creating my account. I'll create the issue when I get all this stuff sorted out.
 
The second question I have, semi-related, is how would you guys suggest doing generational (ie cross-model-version) testing?
 
What I'd like to do is have tests like this:
 
public static class TestFixture{
 
    public static class MyModel{ //v1
        Public int x;
        Public int y;
    }
        
    //And attempt to deserialize (using our moderately customized xstream serializer) it as
 
    public static class MyModel{ //v2
        Public int x;
        Public int y;
        Publix int z;
    }
 
    //in something like this
    @Test
    public void when_we_added_an_extra_int_field_for_feature_1234_we_didnt_break_anything_because_our_deserialization_flow_is_so_nifty(){
          //setup
        OurSerializerThatDelegatesToXStream serializer = testHarness.provideSerializer();
               
        //act
        String serialized = serializer.serialize(makeVersion1OfMyModel());
        MyModel myModelV2 = serializer.deserialize(serialized);
               
        //assert
        assertThat(myModelV2.z).followsProperDomainLogic();
    }
}
 
But of course Javac is going to complain about 2 'MyClass'es.
 
Any suggestions?
 
I was thinking about trying using 2 different canonical names (so MyClass1 and MyClass2), and then add an entry to the aliasMap as part of the setup logic to tell XStream that MyClass1 is-a MyClass2.
 
But since that doesn’t involve nearly enough overly complex code, the other thing I was thinking of doing is copy-pasting class files around and then manually loading via some stupidly sophisticated mechanism. With a couple extra ant targets I could probably even make this bearable.
 
Thanks for any help,
 
Geoff Groos, Lead Developer, Empower Operations Corp.
778 846 8593,
 
 
-----Original Message-----
From: Jörg Schaible [[hidden email]]
Sent: February 18, 2015 11:42 AM
Subject: [xstream-user] Re: Make UUID an Immutable type by default
 
Hi Geoff,
 
Geoff Groos wrote:
 
> Hey guys,
>
> We’re just about to go to version 1.0, so I’m running over every piece
> of tech-debt I can think of to make sure all my ducks are in a row,
> and I found this in our project file (an XML serialized model):
>
>       <ProjectState.ImmutableMomento>
>         <associatedRunId>b723fec2-50f9-45fa-9a41-
fee8d022b544</associatedRunId>
>         <!-- ... -->
>       </ProjectState.ImmutableMomento>
>       <ProjectState.ImmutableMomento>
>         <associatedRunId
>        
> reference="../../ProjectState.ImmutableMomento/associatedRunId"/>
>
> I cant think of a good reason for a UUID not to be immutable by default.
> Doing oneID == anotherID has to be as taboo as aString ==
> anotherString to anybody whose willing to use a UUID object, meaning I
> don't think there’s any reason to preserve reference equality in serialization.
 
You're absolutely right. Can you open a JIRA ticket to track the issue, please? Simply follow instructions at http://xstream.codehaus.org/issues.html
 
Cheers,
Jörg
 
Sad to say, but 2 hours earlier, and it would already have been part of the new release :-/
 
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
 
 
 
Reply | Threaded
Open this post in threaded view
|

RE: Re: Make UUID an Immutable type by default

Jörg Schaible-2
Hi Geoff,

Geoff Groos wrote:

> Thanks Jörg,
>
> I created an account but have run into some http:500s and what-not from
> jira while creating my account. I'll create the issue when I get all this
> stuff sorted out.
>
> The second question I have, semi-related, is how would you guys suggest
> doing generational (ie cross-model-version) testing?
>
> What I'd like to do is have tests like this:
>
> public static class TestFixture{
>
>     public static class MyModel{ //v1
>         Public int x;
>         Public int y;
>     }
>
>     //And attempt to deserialize (using our moderately customized xstream
>     serializer) it as
>
>     public static class MyModel{ //v2
>         Public int x;
>         Public int y;
>         Publix int z;
>     }
>
>     //in something like this
>     @Test
>     public void
>    
when_we_added_an_extra_int_field_for_feature_1234_we_didnt_break_anything_because_our_deserialization_flow_is_so_nifty()
{

>            //setup
>         OurSerializerThatDelegatesToXStream serializer =
>         testHarness.provideSerializer();
>
>         //act
>         String serialized = serializer.serialize(makeVersion1OfMyModel());
>         MyModel myModelV2 = serializer.deserialize(serialized);
>
>         //assert
>         assertThat(myModelV2.z).followsProperDomainLogic();
>     }
> }
>
> But of course Javac is going to complain about 2 'MyClass'es.
>
> Any suggestions?

Why don't you simply take the XML representation of model 1 and deserialize
it into model 2? Why do you still need to generate the XML representation of
model 1?

> I was thinking about trying using 2 different canonical names (so MyClass1
> and MyClass2), and then add an entry to the aliasMap as part of the setup
> logic to tell XStream that MyClass1 is-a MyClass2.
>
> But since that doesn’t involve nearly enough overly complex code, the
> other thing I was thinking of doing is copy-pasting class files around and
> then manually loading via some stupidly sophisticated mechanism. With a
> couple extra ant targets I could probably even make this bearable.

The strategy to handle newer versions of a class depends on the type of
modification. There's no general rule.

See http://xstream.codehaus.org/faq.html#Serialization_newer_class_versions 
for some ideas.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email