Thanks Dan... On Wed, November 16, 2011 00:25, Dan Haywood wrote: > On 15 November 2011 09:27, Kevin Meyer wrote: > >> I'm using the SqlObjectstore, with the SqlOidGenerator by default. >> Mostly, this is fine. >> >> But now when I create a (Member) object that needs to be persisted >> via the REST service, the oid has already been assigned, and I have >> no method of replacing the oid in the ObjectAdapter with the ID from >> Joomla!. >> > > How is the object being created? There's a whole lifecycle for Oids, with > the OidGenerator having a createTransientOid() method as well as a > convertTransientToPersistentOid() method.
Yes, but see below - I don't want to also recreate a "split" OidGenerator implementation - I'm not sure it is always clear, by looking at the OidGenerator interface, that I can always know if the Oid is for a Member object or not. This is critical. >> This action is occuring within the context of the ObjectStore#execute >> method, while executing a CreateObjectCommand. >> >> Is there any reason why I can't change the visibility of setOid(Oid oid) >> on PojoAdapter to public, so that I can replace the oid with the value >> returned via REST? Will anything go horribly wrong with changing oid's >> like this? >> > > Yes, something will go horribly wrong ;-) No matter - I think my solution will be to create another custom field in the Joomla/Community Builder user table, to store the Isis (Sql) pk_id. I thereafter *ignore* the Joomla/CB id, and only refer to the Isis ID, if a reference by ID is used. >> I don't really want to replace the SqlOidGenerator with a >> MixedOidGenerator, which splits out oid generation, too. >> >> Reminder: only Member objects are persisted by REST, while all >> others are persisted by the SqlObjectStore.
