On 16/11/2011 07:53, Kevin Meyer wrote:
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.
Hmm, I see. But I think that would be the right thing to do.
Most of the OidGenerators encode the domain type within them. Does the
SqlOidGenerator do so also? If so, I would have thought that you could
extract that info and then switch upon it.
Or, a bit more hacky, you could, perhaps, use a different format when
generating Oid as a hint. eg use some sort of prefix to indicate members.
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.
That also seems reasonable. And easier, too.
Dan
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.
