good case for switchable object or something else?

adamtuliper posted on Wednesday, July 01, 2009

Lets take a scenario in the case of Books and Book objects.
Usually we load everything in the Books class and enumerate, etc. But we will not add new items to this collection and call save on the collection because when a new record is created we need the key back right away to set some other object information. We cannot call Child.Save() directly, and there is no parent collection at this point, we create one Book and want to insert it into the db and get its ID back.

Would this be a case for a switchable object or something else?

pseudo code using fake objects:

foreach(RareBook rareBook in rareBooks)
{

Book newBook = Book.GetBook();
newBook.Whatever=....;
newBook.Save()
--here we need the id
rareBook.BookId = newBook.BookId;
}

JoeFallon1 replied on Thursday, July 02, 2009

Your pseudo code won' t work because the ID will never come back from the database due to this line of code:

newBook.Save()

It should be:

newBook = newBook.Save()

I am not following the pseudo code very well - why are you calling GetBook instead of CreateBook? Why do you need the ID "right away"? Why not just leave rareBook with a fake ID until you do call save on the collection?

Joe

 

 

adamtuliper replied on Tuesday, July 14, 2009

yes.. the pseudo code should have CreateBook, my bad.As to your question why do you need the ID now.. that is the entire issue. You need the id to update other objects. There are other objects that for performance reasons aren't loaded/linked here we just need to know that once we get an id back we need to call another procedure to update the database to give it this new id, and this _has to_ be done after every record. I did eventually implement it as a switchable object and the world seems to be a better place now : )