Replicate or not to repli... what?
Posted on 2004-12-10 02:57:03 EET.
What's the idea of repligard? Export all changed records to xml file and import this file to another database. So, when you add article and its parameters , their corresponding fields (changed and updated) in repligard's table are updated , and repligard knows that this record should be exported.
How that looks with Staging/Live setup? Not approved article will be not exported
( and its parameters and blobs ) while repligard will update these records as already exported. Approving article doesn't update parameters and blobs, so another export
makes only article exportable. Any article's method or function which updates anyhow article's record , update only article's record and its repligard's entry.
I spent only few hours to resolve this "bug". I thought that we may treat article's or any other object's paramaters and blobs as its real properties. The same way which mgd_get_xxx makes properties from parameters. Cool. Only few hours to resolve issue with application like repligard. I used defined guid in repligard's conf to make export fast.
When I decided to test how this work with custom export when <replicate all> is set to "yes" I felt big ( read : huge ) headache .
Repligard has no one common way of doing exports. It depends on what is in configuration file , what is in repligard's args etc etc, so all what was found is useless cause it's high time to start another debugging , another logs , another searching for how, when and why. This is not funny if you think about sources like midgard-php which uses Zend where many things are hardcoded. Repligard has huge amount of structures, hashes and glists. You may even find yourself VERY confused when you start to work with RListEntry and your code produces segfaults.
Anyway , I decided also to add repligard's switch '-w' which forces parameters and blobs records to be exported when "parent" object is to be exported too.
You may get latest CVS to use Staging/Live and have the "whole" objects in staging and live databases.
export.c diff
How that looks with Staging/Live setup? Not approved article will be not exported
( and its parameters and blobs ) while repligard will update these records as already exported. Approving article doesn't update parameters and blobs, so another export
makes only article exportable. Any article's method or function which updates anyhow article's record , update only article's record and its repligard's entry.
I spent only few hours to resolve this "bug". I thought that we may treat article's or any other object's paramaters and blobs as its real properties. The same way which mgd_get_xxx makes properties from parameters. Cool. Only few hours to resolve issue with application like repligard. I used defined guid in repligard's conf to make export fast.
<replicate >
<resource guid="some_guid"/>
</replicate>
When I decided to test how this work with custom export when <replicate all> is set to "yes" I felt big ( read : huge ) headache .
Repligard has no one common way of doing exports. It depends on what is in configuration file , what is in repligard's args etc etc, so all what was found is useless cause it's high time to start another debugging , another logs , another searching for how, when and why. This is not funny if you think about sources like midgard-php which uses Zend where many things are hardcoded. Repligard has huge amount of structures, hashes and glists. You may even find yourself VERY confused when you start to work with RListEntry and your code produces segfaults.
ext = g_new (RListEntry, 1);Not a big thing , but in this case guid is gboolean, id is a char guid and table is the only one what you thought of :)
ext->guid
ext->type
ext->id
Anyway , I decided also to add repligard's switch '-w' which forces parameters and blobs records to be exported when "parent" object is to be exported too.
You may get latest CVS to use Staging/Live and have the "whole" objects in staging and live databases.
export.c diff