Hello Daniel,
you wrote:
>> Midgard 1.2.6 progress [snap]... Currently it is expected that the
>> release would be feature-complete within two weeks when Alexander
>> gets his new XML-based replication utility Repligard integrated to
>> the system.
> I�ve seen such a system in Allaires Spectra system
> (http://www.allaire.com/Products/Spectra/). They use wddx to
> replicate sites. Since they`re using some type of object-oriented
> ids, this works ok. What way will Repligard go?
It will go to XML dump of Midgard objects. Each object presented as a
set of XML elements (version of DTD that is under development could be
downloaded from CVS /midgard/proposals). Each element has an ID
property (IDP) which is different from real ID field in that it is
unique along whole DB and is very similar with Midgard 2.0 ID. Thus,
an article ID#1 and a topic ID#1 from DB will have different IDPs in
XML dump.
Each Midgard database will contain additional table called
'repository'. We place references between real IDs of objects and IDPs
in it together with last update time stamps for each object. It allows
to transfer objects between different DBs and update them without
requiring exact correspondence between remote and local ID of object
(they even aren't stored in XML dump). Instead, Repligard will check
repository for corresponding IDP existence and fetch real ID from it
if successes. Then time stamp will be checked and object updated
(there will be also a 'force' mode when time stamps will be ignored).
If object does not exist, it will be created.
Every time when object is changed (created, updated, or deleted) in
the database, corresponding record in repository is automatically
changed too. It is already done in Midgard 1.2.6-beta 2 which will be
available soon. Thus, for transferring data from development server to
production one you'll need just dump database into XML using Repligard
and update second database. The same for transferring data from
production to development servers (user feedback, etc..).
One unique feature of Repligard which I strongly wish to implement, is
automatic update of IDs which can be found in PHP scripts being
transferred via Repligard. The issue is in unnecessary identical IDs
in different databases. Solution is to replace IDs with IDPs when
dumping and replace them vice versa when other database will be
updated. It requires lookup table for ID and IDP correspondence but we
already have it as repository. The main trick is to scan script body
and change all occurrences of mgd_xxx functions with exact ID
arguments by their portable equalents. For example, suppose we have
the following script:
<?php
$topic=mgd_get_topic(15);
?><h1>&(topic.name);</h1><?
$articles=mgd_list_topic_articles($id);
while($articles && $articles->fetch())
{
?><b>&(article.title);</b>: &(article.abtract);<br><?
}
?>
It will be changed like this one (the real syntax for writing IDP
inside PHP scripts will probably differ):
<?php
$topic=mgd_get_topic(<<@@a65a65a7fae72919283cba3b2@@>>);
?><h1>&(topic.name);</h1><?
$articles=mgd_list_topic_articles($id);
while($articles && $articles->fetch())
{
?><b>&(article.title);</b>: &(article.abtract);<br><?
}
?>
The only problem which still remains unsolved is when real ID is
assigned to some variable first and the latter one is used as a
reference later. But I don't see any solution for it, and this
technique is not good anyway.
I would like to see any comments for Repligard behaviour.
Best regards,
Alexander mailto:[EMAIL PROTECTED]
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
