<div dir="ltr"><br><br><div class="gmail_quote">2008/8/10 Adrian Rossouw <span dir="ltr"><<a href="mailto:adrian@bryght.com">adrian@bryght.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><br><div><div class="Ih2E3d"><div>On 10 Aug 2008, at 3:19 PM, Ernst Plüss wrote:</div><blockquote type="cite">With the help of a GUID and a timestamp of the last write access in every table it would be easy to synchronize Databases. If you want to synchronize only certain elements like varialbes, nodes, users, configuration etc. modules could provide a hook which<br>
</blockquote></div>Not all tables have timestamps, and it would require adding a whole mess of extra columns.</div></div></blockquote><div class="Ih2E3d"><br><br>Adding Timestamp columns would not be to hard. For MySql you don't even have to change the module code since the DB does everything for you. Up on every write operation a new timestamp is set automatically.<br>
The GUID would be a little bit harder. AFAIK there's no automatic insertin of GUIDs for primary keys. But the functionality could be integrated in the db_xyz functions.<br> <br><blockquote type="cite"><span style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><ul>
<li>just lists the db table to snychronize</li><li>gets the result of db compaire and let the user decide what will be pushed to the other side.</li></ul></span></blockquote></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div></div>That's a lot of functionality, considering the weird merging of tables, and additional foreign keys. Take for example<div>a simple single -> multi relationship. You'd have to compare the bunch of them, and understand how to generate them all.</div>
</div></blockquote><div><br>For new and updated rows it's actually very easy. First check for the timestamp. Then check for the GUID. If it's there update the row from the source db if not insert it. This works always and is not dependant on the relationships between the tables.<br>
The hard things are the deleted rows. You have to check for every GUID in the destination db whether it still exists in the source db. If you have a lot of data this can take a some time.<br><br>The hook is meant as a help for modul developers in case you don't want to migrate a whole db but you let's say a certain node type. So you can do some filtering or what every makes sense.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>All this stuff is already in most of the _load functions. It's also a LOT easier to compare 2 objects to each other </div>
<div>(take the diff module for instance).<br></div><div><br></div><div>Also, the db updates then get related very directly to the schema the modules export.</div><div class="Ih2E3d"><div><br></div><div><blockquote type="cite">
Both things could be handled by the db_query() function, to make sure no one forgets to touch the access timestamp and creates accurate GUID's.<br></blockquote><br></div></div><div>I think that perhaps db_query is too low a level for this, as that would add extra cycles on every single query done to the database, and probably</div>
<div>also parsing the query (or changing all the db_query calls in core with extra parameters).</div><div><br></div><div>And it's also not that hard to make sure the access stamp isn't changed, and is only related to nodes.</div>
</div></blockquote></div><br></div>