Updating in PLINQO

[GoogleCodeExporter]

Not really an issue more of a question , is there a better forum maybe 

BUT 

i am activly trying to work with Plinqo . Updating seems a bit clumsy or I 
have it wrong (as usual) 

I see the logic but if I am correct you have to specify all fields 
individually 

eg Task.Update(t=> t.taskID =1 , new Task {FirstName ="Test")) ;
etc 

I tried substituting my updated entity (var updatedTask) for the new task 
{  } but I get a SQL syntax error .

ie 
Task.Update(t=> t.taskID =1 , updatedTask) 

If it could work like that it would be first prize.

Do I imply that in the new Task{  ...} I need to add in all properties 
that have been changed. If so its a bit laboursome in a real world 
application , even if you knew what had changed . For a typical entity you 
would have to specify all properties .

Am I missing something ?

I appreciate its a single db activity as opposed to the Linq-SQL get the 
entity , update it and then submit as 2 db activities.

I see 2 alternatives , use reflection to swap the properties of 2 entities 
and then submit (ie still 2 activities)

or

Use code generation in the manager class generation to add in all the 
properties for that entity .

Does that make sence?

Cheers 

Mike

Original issue reported on code.google.com by mike.one...@za.sabmiller.com on 9 Sep 2009 at 5:55

[GoogleCodeExporter]

Unfortunately, the code is using an expression tree to know what to update. The
expression its looking for is MemberInitExpression, which is the new { Property 
=
something } syntax.  Otherwise, there is no why to know what properties were 
updated.

You can use DataContext.Table.Attach(entity, true) as an option.  

Original comment by paul.wel...@gmail.com on 14 Sep 2009 at 2:17

• Changed state: Invalid
• Added labels: Framework-PLINQO

[GoogleCodeExporter]

Is this a detached scenario or are you just trying to update an entity?

Original comment by ejsm...@gmail.com on 14 Sep 2009 at 2:45

• Changed state: AwaitingInfo

[GoogleCodeExporter]

Hi Eric

It was just a general update entity scenario ,I suppose I could Detach , adjust 
and 
re attach as well.

 I got around it by using a template to add another partial class to add another 
couple of methods to the Manager classes. I haven't looked yet how to 
incorporate 
that into the main Manager Template as an add in to teh template.

I created two options ,  to create  the new { .....} of the lambda expression 
and 
loop through the table columns adding in all the properties within it eg 
FirstName = 
updateName.FirstName ++++.

The second option was the traditional <look it up - update it - save it> as 
LINQ-SQL 
in 2 shots . A method ApplyPropertyChanges (original , updated)  to swap the 
properties from the updated to the original.

The other method I added out of interest was an Insert method , however trivial 
, so 
now the manager class exposes a Insert, Delete , Update and Get methods + all 
the FK 
and index lists etc as per a more standard CRUD approach.

One suggestion may be to even combine the Insert & Update to SAVE and use logic 
in 
the manager to decide wether it be an Insert or an Update by inspecting the 
entity 
state.

Other than that I am finding Plinqo a joy , the regeneration of the DBML is a 
vast 
improvement on std.

Mike

Original comment by mike.one...@za.sabmiller.com on 15 Sep 2009 at 5:55

[GoogleCodeExporter]

Sorry for the delay.  Guess the notification email got lost.

I'm not quite sure I understand your scenario.  Why can't you just retrieve the
entity, make changes to it and call SubmitChanges?

Original comment by ejsm...@gmail.com on 18 Sep 2009 at 6:54

[GoogleCodeExporter]

Hi Eric

I thought the table extension .Update did it in one move . 

I had already written a template to swap the properties from one object to 
another 
and then  to "retrieve / swap the paroperty values / submit changes"

I was just wondering how to use the Update  extension

As far as can I see ,when you create the new object with new { FirstName = 
updatedObject.FirstName....} you have to specificy each property anyway so I 
may as 
well use the retrieve / apply changes / submit changes route.

I have got around it now by using the xxManager.cs  & xxxManager.Generated.cs , 
by 
adding a further xxManager.Designer.cs class to add in the extras I need to do 
it .

I must look how to incorporate into the main manager template 

Mike

Original comment by mike.one...@za.sabmiller.com on 21 Sep 2009 at 11:50

[GoogleCodeExporter]

It does do it in one call to the db, but in its only useful if you don't have 
the
entity in memory already.  You already made the call to the db to get the 
entity and
have it in memory.  That is why in your case it's better to just call 
submitchanges.
 the .Update method is useful for doing batch updates where you don't have the
entities in memory already and don't want/need to make the call to pull them 
into memory.

Original comment by ejsm...@gmail.com on 2 Oct 2009 at 7:16

• Changed state: Invalid

[GoogleCodeExporter]

Original comment by ejsm...@gmail.com on 2 Oct 2009 at 7:19

• Changed state: Responded