If you want to have a master "read-only-access" copy, and then only spin off
separate contexts to do updates, that seems like a reasonable design to me.
In that case, you don't have to worry about non-persisted values, and you
can store them in the subclasses. You'd only copy those objects at the time
of update, so you don't need to worry about the non-persisted values. When
the changes were committed, the updated persisted values would automatically
propagate back into your master copy.
I don't think there's any need to unregister the objects when you're done.
Just dereference the data context and the objects and they should all go
away in garbage collection.
If you feel the need to do locking, you can do it in a non-persisted
attribute at the application level, but I don't see any benefits for doing
so from what you've described unless you've got concerns about players
overwriting each other's changes.
The one nice thing about Cayenne is that you should be able to scale this
application pretty easily. You can use the remote notification stuff to
have parallel servers running once the user base grows to require it.
-Mike
Dave <sanxion200..ahoo.com> wrote:
> Dave wrote:
> > Are DataObject instances copied in
> > the DataContext.localObjects() method?
> > I'm worried about any custom fields not
> > part of the values Map.
>
> Mike wrote
> > Yes, it will create a new data object pointing at
> the same database record.
> > What sort of fields do you have that you're not
> persisting?
>
> Non persistant fields that only are relevant to the
> ongoing session. E.g. if the Player has joined a
> ChatRoom, any movements, moods and so on.
> They add up to become quite a few. From what I
> understand there are several possibilities. Let me see
> if I understand them.
>
> POSSIBILITY 1
> Mike wrote:
> "you might create a server object that internally
> delegates to a cayenne object for persisted values"
>
> I'm not sure I understand how this would solve the
> problem with copies? I need a Context in the main
> thread that loads the game, all cities, houses, rooms
> and furniture.
> To safely update them, as we've discussed, I need to
> move them to a seperate context with localObjects().
> Hm. Is there something I'm missing?
>
>
> POSSIBILITY 2
> Mike wrote:
> "Another possiblity is to create your own
> localObjects() method that calls the cayenne method,
> then calls your custom code to copy over your
> non-persisted values afterward."
>
> I guess the main Context should keep track of ALL the
> loaded instances of Player, City, House, Room and
> Furniture. Any other contexts, residing in Player,
> should only be used for updating rows. In that case
> I'm not sure I need my non-persitant fields copied.
> I could create a copy of the object I wish to update
> using localObjects() in the player Context. Change
> persistant fields. Commit changes. Probably unregister
> the object in the player context, as it was temporary
> anyway. Is this a way to go?
>
> POSSIBILITY 3
> Dave wrote:
> "use the extended class generated by cayenne for my
> custom fields and methods"
>
> I'd really like to do this. Perhaps this works with
> what is described above? Are there any other options
> we've overlooked? Or am I ready to charge ahead?
This archive was generated by hypermail 2.0.0 : Mon Dec 20 2004 - 16:08:07 EST