Re: JavaClient offline storage / replication
Re: JavaClient offline storage / replication
- Subject: Re: JavaClient offline storage / replication
- From: Jean-Francois Veillette <email@hidden>
- Date: Fri, 17 Apr 2009 07:47:52 -0400
Le 09-04-16 à 07:50, Anjo Krank a écrit :
You could probably also serialize Adaptor ops that occur after
ec.saveChanges() using sth like the ERXAdaptorOperationWrapper and
have some custom code dealing with conflicts. At least this would
allow you to handle things in code, not in SQL.
I had to sync 2 deployement site of the same WO app. It didn't have
to be real time, just sync at will. So my first thought was to save
operation on one site, transfert them on the other site and reapply
them over there.
I have part of it implemented, only the 'saving' part.
It simply a delegete that implement
databaseContextWillPerformAdaptorOperations(...), iterate over the
list of operations and create new EOAdaptorOperation that save a
serialized version of desired operations.
Here is a code snippet :
public NSArray databaseContextWillPerformAdaptorOperations(final
EODatabaseContext dbCtxt, final NSArray adaptorOps, final
EOAdaptorChannel adChannel) {
NSMutableArray results = new NSMutableArray();
log.info("!! databaseContextWillPerformAdaptorOperations: ");
log.info(adaptorOps);
log.info("---");
Enumeration enim = adaptorOps.objectEnumerator();
// WOXMLCoder coder = WOXMLCoder.coder();
XStream xstream = new XStream(new DomDriver()); // does not require
XPP3 library
EOEditingContext ec = new EOEditingContext();
EOEntity entityTransaction = EOUtilities.entityNamed(ec,
Transaction.NomEntite);
EOEntity entityOperation = EOUtilities.entityNamed(ec,
Operation.NomEntite);
Object transactionPk = sequenceClefPrimairePourEntite(adChannel,
entityTransaction, Transaction.ClefPk);
Object[] transactionObjs = { Transaction.CodeStatut_Genere, new
NSTimestamp(), Site.clefSiteCourant(), transactionPk };
NSDictionary transactionValues = new NSDictionary(transactionObjs,
transactionKeys);
EOAdaptorOperation transactionAdaptorOp = new
EOAdaptorOperation(entityTransaction);
transactionAdaptorOp.setAdaptorOperator(1);
transactionAdaptorOp.setChangedValues(transactionValues);
results.addObject(transactionAdaptorOp);
while (enim.hasMoreElements()) {
EOAdaptorOperation op = (EOAdaptorOperation) enim.nextElement();
results.addObject(op);
ERXAdaptorOperationWrapper wrap = new ERXAdaptorOperationWrapper(op);
String xml = xstream.toXML(wrap);
log.info(xml);
Object operationPk = sequenceClefPrimairePourEntite(adChannel,
entityOperation, Operation.ClefPk);
Object[] objs = { Operation.CodeStatut_Genere, op.entity().name(),
xml, operationPk, transactionPk };
NSDictionary values = new NSDictionary(objs, operationKeys);
EOAdaptorOperation adaptorOp = new
EOAdaptorOperation(entityOperation);
adaptorOp.setAdaptorOperator(1);
adaptorOp.setChangedValues(values);
results.addObject(adaptorOp);
}
return results;
}
It does work in the sense that operations does get serialized and
saved to the bd. But I never push this pet project further so that I
never got it to transfert and sync over 2 deployement sites. So it
was never really tested, it's more at the state of a prototype
actually more than anything else.
The model is simple, 3 entities : Site, Operation and Transaction
Site <-->> Transaction
Transaction <-->> Operations
If you would like to take a look at it, let me know, I can send it
all, it was all done on my spare time for a non-profit organisation.
- jfv
Cheers, Anjo
Am 16.04.2009 um 04:44 schrieb John Ours:
My main concern with trying this with WebObjects would be, as
others have said, trying to sync the persistence layers. Even if
you could get it to work it would be horribly inefficient. In
every system we've ever built like this we've handled the data sync
at the database level through either OTS or custom replication.
Hypothetically this approach should work with WO...the clients
always write locally and the sync is database-to-database whenever
a connection becomes available.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden