Id cannot be assigned to

Hi,

I have a piece of code to save a page entity from my asp.net web form code behind.

If the entity already existed it's id is in my idHiddenField.

I am getting the error: Mindscape.LightSpeedEntity<int>Id cannot be assigned to.

How would I do this then?

int id = 0;

Since the entity already existed, you should not be creating a new Page entity and trying to assign it the same Id -- you should be loading the existing entity.  Otherwise when LightSpeed tried to insert the new entity, you would get a key constraint violation.

So your code should look something like:

BL.Page page;
BL.PageRepository pr = new BL.PageRepository();

if (String.IsNullOrEmpty(idHiddenField.Value))
{
  page = new BL.Page();
  pr.Add(page);
}
else
{
  page = pr.FindOne<Page>(Int32.Parse(idHiddenField.Value));
}

// modify page fields and save it as before

 To put it into context. I am working in a disconnected stateless manner.

I have a usercontrol with a gridview (that lists all entities) and a panel that is used for new and editing.

When selecting edit on my gridview role I Get a page based on the id and populate my panel fields.

Then when I want to save back to the database without having to first request the entity from the db before saving. I was able to do this easily with linq to sql.

LightSpeed has only limited support for that approach: for us, the load-modify-save pattern is the expected way of working with entities in a Web application (see the samples included with LightSpeed), because this allows domain logic to have full play.

However, if you want to perform an update without a prior load, then you can do so using the IUnitOfWork.Update(Query, object) method, passing in your case a query by ID and probably an anonymous type e.g.

uow.Update(new Query(typeof(BL.Page), Entity.Attribute("Id") == id), new
  {
    ApplicationId = ...,
    Content = ...,
    Name = ...
  });

Obviously in this case care is required if renaming fields as the compiler will not detect that the anonymous type no longer matches; an alternative approach is to use a dictionary and the generated XxxField name constants.

But we would normally recommend the load-modify-save approach.  I'm guessing your concern is performance (the cost of the select query) but this shouldn't be a big deal in a normal system, and given that UIs often end up echoing back the updated entity to the user (as confirmation or just as part of a refresh) it's not unusual to have to select it anyway.  Plus load-modify-save will be much more robust if the entity subsequently acquires business logic such as whole-entity validation where it may be important that all fields of the entity are up to date.

Really? I'm still not really sold on that approach. The going back to the database again just doesn't make sense to me..

I thought this was the advantage of using Light Speed over Linq to Sql.. I guess I was wrong..

Which example is just a straight web form not mvc?

We may be able to support this model once we have partial updates (at the moment LightSpeed saves all (non-lazy) fields, which means it needs to load all fields, which pretty much forces the load-modify-save approach), which are coming in 3.0.  I've logged a feature request for it.

For Web Forms samples, see the Poker and Store samples.

 Thanks alot!

I'm just trialing at the moment before we decide to purchase..