New Posts New Posts RSS Feed: Saving Changes to POCOs
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Saving Changes to POCOs

 Post Reply Post Reply
Author
matt.cavagnaro View Drop Down
Newbie
Newbie


Joined: 09-Aug-2012
Posts: 7
Post Options Post Options   Quote matt.cavagnaro Quote  Post ReplyReply Direct Link To This Post Topic: Saving Changes to POCOs
    Posted: 30-Nov-2012 at 8:55am
I've recently implemented a ConventionBased ServiceProvider to Query for a FCC POCO object which is a subset of an existing Entity.

I have not been able to figure out how to persist changes made to the POCO to the table it is a subset for during SaveChanges.

I've read through these links multiple times and have not been able to figure out how to make this work.
http://drc.ideablade.com/xwiki/bin/view/Documentation/poco-service-provider-class
http://drc.ideablade.com/xwiki/bin/view/Documentation/poco-save-mechanisms

I've tried using the EntityManager from the POCO to query for and save changes to the original object in the DB but an error is thrown stating recursive saves are not supported.

Is there any better documentation/code samples for this?


Edited by matt.cavagnaro - 30-Nov-2012 at 8:56am
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 30-Nov-2012 at 10:38am
As you've found, you can't use an EntityManager from your POCO service provider or adapter to save an entity.  The save is recursive to DevForce, and once a save is in progress additional SaveChanges calls are not supported.
 
In general, POCO is not really intended for database-backed objects, and any insert/update/delete activities should not be using an EntityManager in the provider or adapter.
 
I'm not sure I understand your use case, though, and maybe POCO is not a good fit for this anyway.  If your FCC type is a subset of an existing entity type, will standard inheritance work - maybe with an abstract base entity having the FCC and other entity type as sub-types?   More information on inheritance is here - http://drc.ideablade.com/xwiki/bin/view/Documentation/model-advanced.
 
 
 
Back to Top
matt.cavagnaro View Drop Down
Newbie
Newbie


Joined: 09-Aug-2012
Posts: 7
Post Options Post Options   Quote matt.cavagnaro Quote  Post ReplyReply Direct Link To This Post Posted: 30-Nov-2012 at 10:50am
My use case is as follows.

Given a DB backed entity like Player
class Player()
{
    Guid UniqueID { get; set; }
    string FirstName { get; set; }
    string LastName { get; set; }
    bool IsActive { get; set; }
    string TeamName { get; set; }
    string Position { get; set; }
    byte[] Picture { get; set; }
}


And a POCO class for a query on Players to project into:
class PlayerLite()
{
    Guid UniqueID { get; set; }
    string LastName { get; set; }
    bool IsActive { get; set; }
}


I need to query many objects like Player at once. to make the query more performant I've used a POCO to only pull down the data I need to interact with. In reality my Player table is much larger than this. And I'd like to avoid pulling down heavier properties like Images and other Navigation Properties.

In the portion of the app this is used for the User is only ever expecting to modify a handful of properties for a given Player entity.

I guess I don't understand the function of wanting to save the POCO to somewhere that is not it's data source, like an XML file. To me this sounds like I could query for a subset of the object I wanted to modify, make a few changes, and be able to map the properties on the POCO back to the DB backed Entity.

Is there another way you'd suggest doing this?
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 30-Nov-2012 at 12:31pm
You have a few different options.
 
I assume you're projecting into the PlayerLite type from a query, so you shouldn't need a POCO service provider or adapter at all.
 
One option would be to query for the full Player entity when changes are required.  The Player would then be changed and saved.
 
Another option would be to make changes to the PlayerLite object, and in an EntityQuerySaveInterceptor intercept the save of the PlayerLite, and there query for and modify the Player in the provided EntityManager.  You'd also have to detach the PlayerLite from the EM so that DevForce won't still try to save it as a POCO, or alternately keep a stub POCO save method.
 
Another option would be to use table splitting for these entities, so that both are full-fledged entities with a 1-1 relationship between them, and either could be modified as needed. 
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down