PLINQO Equals method only generated for Composite Objects

[GoogleCodeExporter]

What version of the product are you using?  6.0.3 with PLINQO-NH template r2476

What steps will reproduce the problem?
1.  Generate PLINQO-NH project.
2.  Generate Outputs
3.  Look in Entity that does not have composite key, there is no equals method.
4.  Look in Entity that has a composite key, there is an equals method.
5.  Look in Entity.generated.cst and see:

        <% if (SourceEntity.Key.IsComposite) { %>

        #region Composite Key Overrides

        <%= GeneratedCodeAttribute %>
        public override bool Equals(object obj)
        {

And this is the only override of Equals.

Also I question the validity of only comparing the "key" values to determine if 
objects are equal.  It should look at all properties, or at least all intrinsic 
properties.

dbl

Original issue reported on code.google.com by ibflyfis...@gmail.com on 30 Mar 2012 at 3:52

[GoogleCodeExporter]

Yes,

I believe it should look at all non computed columns. Also, it should implement 
a GetHashCode override. What do you think with this proposal?

Would you mind submitting a patch for this?

Original comment by bniemyjski on 11 Apr 2012 at 4:45

• Changed state: Investigating
• Added labels: Type-Enhancement, Framework-NHibernate

[GoogleCodeExporter]

I'm working on this.  Will add the update when I get it working.

Original comment by ibflyfis...@yahoo.com on 11 Apr 2012 at 11:33

[GoogleCodeExporter]

Thanks for helping :). It means a lot.

Original comment by bniemyjski on 12 Apr 2012 at 1:31

[GoogleCodeExporter]

Original comment by bniemyjski on 12 Apr 2012 at 1:31

• Changed state: AwaitingInfo

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Blake,

Turns out that NHibernate accesses the GetHashCode after loading just the key 
properties.  So when it loads the rest of the data the HashCode changes.  This 
causes a problem on update because it thinks that the ID has changed and won't 
allow that.  I'm going to post this on the NHibernate forums and see what they 
say.

So for now I have implemented the Equals and GetHashCode in a similar fashion 
to what was originally in the file but moved it so that its generated for all 
objects not just those with Composite Keys.  

I added an "Equivalent" method that does do a field by field comparison.  I 
also added formatting to the call so that each comparison is on its own line 
and is easier to read.

I tried to keep everything consistent with how the file was written.  Let me 
know if you have an suggestions or changes.

Thanks

dbl

Original comment by ibflyfis...@yahoo.com on 12 Apr 2012 at 5:11

Attachments:

• Entity.Generated.cst

[GoogleCodeExporter]

Hello,

Thanks for your attached changes. 

I've created a patch for this. Is there any chance you could change the 
template logic for GetEquals and GetHashCode. I think it would make more sense 
to just place all the generation logic where it belongs, which also saves from 
doing new line insertion. Also  you can just override the GetHashCode() and 
Equals() methods in your derived entities which makes adding additional methods 
pointless (gotta love the original creator...). What do you think?

Original comment by bniemyjski on 19 Apr 2012 at 7:41

Attachments:

• Issue640.patch

[GoogleCodeExporter]

I had thought about doing that but two things:

I am using the GetEquals to build the GetEquivilant.  - the Entity there 
separates the properties that are part of the key from the other properties.
I was trying to use the structure/format that was already in the file.

I can get rid of the GetEquivilant and GetGetHashCode but maybe keep the 
GetEquals unless you have a better idea.

When I'm done do you just want me to attach it here?  

I also found where all the cref references point to the "Account" class instead 
of the actual class.  I've fixed that as well.

Original comment by ibflyfis...@gmail.com on 3 May 2012 at 4:37

[GoogleCodeExporter]

Hello,

Yes, please attach here. Can you also please update the GetHashCode 
implementation too :D.

Original comment by bniemyjski on 3 May 2012 at 4:52

[GoogleCodeExporter]

Also after looking at it the newline piece for me is a readability issue.  It 
would still be used if you moved the code up into the actual functions so that 
each "operation" is on its own line.  I understand if you don't want it in the 
templates but I like the readability of it that way.

Original comment by ibflyfis...@gmail.com on 3 May 2012 at 4:58

[GoogleCodeExporter]

Not sure what you mean about update the GetHashCode implementation?  If you are 
referring to including all properties instead of just the key properties, I 
haven't resolved the issue where NHibernate and so I've left that 
implementation basically the way it was.

Original comment by ibflyfis...@gmail.com on 3 May 2012 at 5:16

[GoogleCodeExporter]

Yes, I would think the GetHashCode implementation would be calculated using the 
same properties as equals.

Original comment by bniemyjski on 7 May 2012 at 4:28

• Added labels: Priority-High