Duplicate decorations

Hello -

LightSpeed is generating the following code for almost all, if not all, of the properties:

    [System.Runtime.Serialization.DataMember]
    [System.Runtime.Serialization.DataMember]
    [System.Diagnostics.DebuggerNonUserCode]
    public string ShortName
    {
      get { return Get(ref _shortName, "ShortName"); }
      set { Set(ref _shortName, value, "ShortName"); }
    }

I first thought it was caused by upgrading to the latest build, but then I backed out to the May 2 build (the last stable build I have downloaded and tried), and running the tool to regenerate the Model.cs code does the same thing there now.  What changed, what have I done to cause this kind of behavior?

I am also getting the DataMember decoration on the CreatedBy and UpdatedBy properties as well now.  That breaks all kinds of things...

Thanks for any help,

Dave

Hi Dave,

Are you manually specifying DataMember as a custom attribute on your properties? What will have changed recently is that we committed the additions to the designer to control DataMember generation on a per property basis, so I think that would have something to do with what you are seeing.

From memory you were controlling some of the DataMember generation manually before to ensure the properties were not being generated on every association, is that right?

The behavior of the code generation performed by the designer can now be controlled on a per property basis through the properties window on an entity property or an association (you can also specify if DataMember is generated per side of the association and if it also generates one for the Id property on the parent).

Jeremy

Hi Jeremy -

Working the weekend, eh?

If I am manually specifying the DataMember as a custom attribute, I am unaware of it.  I will have to look into that possibility on Monday when I get back to that part of the project.

What I am doing is commenting out the DataMember attribute on the association properties where I didn't want the reverse lookup.  I will look into the new capabilities of the designer when I get back to it, as I was unaware of any changes made in this regard.

Thanks for the response!

Dave

Thanks Dave, let us know what you find.

You would have had to be really looking to notice the designer changes! Those were only added recently and we havnt made any particular noise about them being in. Let us know what you think once you have had a change to take a look, you should find they will give you the precise control needed to decorate your contracts.

Jeremy

Jeremy -

I responded to Ivan in the blog space already, but what I am finding is the Generate Data Member Attribute has been turned off now for all associations by default. That means I get no related records on save or load by default.  This is exactly opposite from what you were doing previously, and creates a ton of work for the user (me).

If that is the intent, I would like to hear the rationale (it probably makes perfect sense, I just would like to hear it).  It may very well be the best way to do things, but it sure broke my model in many ways. If I need to go through and identify the places where I actually want the related records loaded, that's great, you have to choose one way or the other, but a little notice and warning would have been nice...

Dave

Hi Dave,

Yes, sorry about that. We have chosen not to default the generation of DataMember attributes for associations off because it has two implications, both of which are bad as a default.

Firstly it would cause larger graphs of data to be generated when you start sending entities over the wire since the associations will be traversed which in the naive case would case issues fairly quickly particularly when the message size starts exceeding the WCF defaults. The second issue is around circular associations, by default WCF will complain if these scenarios are picked up - they are not a problem if you are using the NetDataContractSerializer (which is what the DistributedUnitOfWork uses, but is certainly not the default for most people), again this just leads to issues in debugging what the problem is since messages are rather arcane WCF issues. WCF is not particularly good for tracking down these issues until you start using the tracing capabilities.

Apologies for not putting out an alert on this, since LightSpeed 4 is still in beta we generally just operate on the basis of changing things as needed but we will try and put out better release notes and maybe a blog post when something like this occurs in the future.

Jeremy

Apology accepted ... ;^)

After working through my model this afternoon, updating all the associations to what I think they should be, I can say I agree with your decision here.  I really like the way it's all coming together.  There are several new properties that you're really going to have to document berfore release, though.  Right now I just change a property and see what happens, and that's OK for a beta version, but decidedly not OK for a release version.

I'm waiting for the documentation to see what some of the more arcane properties are for...

Thanks again, you've got the best ORM on the planet, in my estimation!

Dave

Thanks Dave :)

Which properties in particular are you looking for more documentation on - we can give you some more details now if that would help? 

Jeremy

I would guess most of the properties address scenarios that don't apply to me directly at the moment, but here are a few that I would like a little more explanation as to what their effect is on the generated code, etc.

One To Many Association Properties:

 Backreference (Id) / Collection (Id) Custom Attributes

 Backreference / Collection Resolver

 Key Property Reference

 Select Procedure

Entity Properties:

 Custom Attributes

 Transient

 Optimistic Concurrency Checking

Entity Property Properties:

 Custom Attributes (again)

 Transient (again)

Also, how is Inheritance used for all the above? 

I am a little unclear on how Aggregates affect things, but I know I can dig back through some of the blogs and such and find a good description of how that works, at least in general.

If you have time to fill in some of the gaps in my knowledge, that would be great, but don't feel obligated.  Maybe these topics can be addressed in a blog post, so others could benefit from the information as well.

Thanks!

Dave

Thanks Dave, we appreciate the feedback on what is not clear and we will use this to improve the docs in LightSpeed 4 (and a blog post sounds like a good plan as well!).

As a quick summary:

* Custom Attributes are CLR attributes to be applied to the class or property.  (An association has three properties: the children collection in the parent entity, the parent reference in the child entities, and the FK in the child entities.)  For example you could use this to apply BrowsableAttribute or DisplayNameAttribute for displaying the entity in a property grid.

* Transient means the entity or property is not loaded or saved.  It's rare to model such things in the designer -- usually if you have a transient field you'd be hand coding it in the partial class because it's nothing to do with the LightSpeed model.

* Optimistic Concurrency Checking switches on the LockVersion field, which checks whether somebody else saved an entity while you were editing it.  See Help Topics > LightSpeed > Conventions and scroll down to the description of LockVersion.

The remaining association properties all relate to legacy databases where we can't get away with a nice simple foreign key lookup.

* Association resolvers are for use when you need to run custom logic to look up an association instead of just looking up a foreign key.  The canonical example is when you have a composite FK some of whose columns are part of the PK.  It equates to the AssociationResolverAttribute and should be shunned just as that attribute is.

* Key Property Reference is for when an association doesn't have a separate foreign key, but rather its foreign key is represented by another field in the entity.  The canonical case of this is when the FK is a column in a composite Id.  It equates to ForeignKeyFieldAttribute.

* Select Procedure is for when the association needs to be looked up through a stored proc instead of hitting the table directly to look up a foreign key.

Regarding aggregates, this is a good starting point.

Hope this makes things clearer and thanks again for letting us know what is confusing!

Thanks for the great information!  However, the link you included for aggregate info doesn't work.  Got a better one?

Thanks, Dave

Curse all computers!  Here's the link:

http://www.mindscapehq.com/blog/index.php/2011/01/19/controlling-lightspeed-entity-loading-with-named-aggregates/

If pain persists, google "lightspeed entity load named aggregates" -- first result should be the one.