Oh yes, modules that do this, are designed well and really work and can be easily installed are definitely more than interesting: they empower!
+1 On drupal.org we can all download and use the module and converge our feedback into the issue queue! Looking forward to seeing it! Victor Kane http://awebfactory.com.ar On Sat, Aug 1, 2009 at 10:50 AM, Pierre Rineau < [email protected]> wrote: > Hello all, > > Working on some custom project for my company, I developed a module to > do massive migration between sites. > > This module uses a full OO layer. > > Its internal mechanism is based on abstracting objects to migrate from a > master site to clients. This abstraction defines how to construct object > dependency tree and how to serialize objects. > > Object implementation (node, user, taxonomy, whatever) is really simple > to use, it's only 3 methods classes (register dependencies, save, and > update) using some kind of custom registry for developer to save/get > back data before and after serialization. > > All error handling is exception oriented, and lower software layers > won't fail on higher layers unrecoverable errors. > > Object fetching is based on a push/pull mechanism. Server push the sync > order, client responds OK or not. If OK, it creates a job using DataSync > module which allow it to run as CLI thread (which won't hurt the web > server, and allow us a larger memory limit at run time). DataSync module > uses MySQL transactions (shame it's only MySQL compliant, but I hope it > will evolve, I'm thinking about PostgreSQL). > > During the DataSync job execution, client will pull an original set of > content, and browsing it will do incremental dependencies fetching (by > pulling again server), based on xmlrpc (fetching component is also > abstracted, and could be any other communication method than xmlrpc). > > To be unobtrusive on the system, smart unset() is done after building a > dependencies subtree, and there is a recursion breaker in case of > circular dependencies. > > This module was created because the deploy module seems to be so > unstable, I did not want to risk client's production sites to run with > it. I started implementation of some sort of "deploy plan", using > profile based on views, you construct a set of views, saved them in a > profile, then all objects that these views reference will be > synchronized. > > Right now, the module fully synchronize taxonomy and content types, > partially synchronize users (including core account information and > passwords), and I have a small bug left to handle with nodes (revision > problem I think). > > There might be a performance or overhead problem with this conception > with a very large amount of data, it could break easily. The only way to > be sure it won't break is I think to migrate stuff with a numerous small > set of data. But the problem doing this is that it will be really hard > to keep the transactional context of DataSync module. > > There is a lot of other custom goodies coming. > > First thing is, what do you think about such module, should I commit it > on drupal.org? Is there people interested? > > And, now that I described the module, what name should I give him, > considering the fact I'll probably commit it on drupal.org, if people > are interested. > > I though about "YAMM" (Yet Another Migration Module), or YADM (Yet > Another Deployment Module). > > The fact is there is *a lot* of modules which want to do the same thing > as this one, I just want a simple an expressive name. > > Pierre. > >
