Re: [Modeling-users] N-tier development and modeling

[Sebastien B. <sbi...@us...>]

        Hi Tom and all,

Tom Hallman <hal...@dm...> wrote:
> Greetings to all,
>=20
>    It is my hope to draw from the experience and expertise of those among=
 you
> who are more familiar with Modeling than I.
>=20
>    Here is the situation: my colleagues and I are attempting to put toget=
her a
> framework using an N-tier methodology, with the client software interfaci=
ng to
> the server/database backend via remote procedure calls (RPC). For us, Mod=
eling
> will serve as a large part of that backend, with an API written overtop. =
The
> client will make calls to this API, and all will be grand.

Nice!

>    The problem we are having is that of maintaining state between the ser=
ver
> and the client. For example, if we fetch a set of Person objects to be
> displayed on the client, and then want to perform a delete on one particu=
lar
> Person object, how do we know which Person to delete? Modeling seems to w=
ork
> wonderfully up to where there is no RPC necessary, but once we add a split
> over the RPC interface, Modeling seems to lack a natural way to refer to
> objects across that divide.
>=20
>    One thought we had is to set the primary (and foreign?) keys as class
> properties, such that we can refer to them across RPCs. This is somewhat =
of a
> hybrid of Modeling and the old-fashioned "use the primary key to get what=
 we
> want" method.
>=20
>    Any thoughts on this matter would be greatly appreciated! Thanks so mu=
ch
> for your time.

Working with PKs and FKs would work, but it is definitely not the
cleaniest way to identify objects wrt the framwork.  There is a
dedicated component for that purpose: the objects' GlobalID (it can be
accessed through obj.globalID() or by asking the EC for the
globalIDForObject()); a GlobalID is a unique identifier for an object/a
row inside a framework.

  Two different kinds of GlobalIDs exist:

- KeyGlobalIDs identify objects that exists in the database, and
  uniquely identify such an object in whatever EditingContext.

- TemporaryGlobalID uniquely identifies a new object that is not saved
  in the database yet.  Because the objects is not saved, such an
  globalID can identify the object only in its referring EC, or in one
  of its children.

Both can be easily marshalled/unmarshalled, e.g. transformed to strings
and back to GlobalIDs; for example, a KeyGlobalID can be rebuilt from
its entityName() (string) and its keyValues() (dictionary).

  Last, given that you have a gid, you get the corresponding object in a
  EC simply by calling: obj=3Dec.faultForGlobalID(gid, ec)

Does this fulfill your needs?

I still have a question: will you also have an EC on the remote-side?
I'm asking this, because if this is the case the synchronization of the
client's EC and the server's one could be more complicated then simply
identifying objects by their globalIDs and passing some of their changed
attributes. And since I'm currently working on synchronization between
ECs and optimistic locking (working well, I think a first draft wil be
available this week-end), maybe I could also begin to think of such a
"remote" synchronization, esp. if you have a use-case and can consider
testing it in your own app.

-- S=E9bastien.