Update "Existing Modules" section with comments on alternatives: node_export, feeds and bundle_copy [#2101035]

Hi folks - thanks for your great efforts making an all-in-one solution for import and export of data to help ease deployment.

I'd like to request if you could comment on these modules as they are not yet mentioned on the project page for Data export import in section "Why were no existing modules suitable", please.

node_export and feeds - I would expect to use these modules together: node_export to well, export, obviously and feeds to import. (But what I like about your module is that it's an all in one solution so I'd hope that it means less thinking about making the output of the export compatible with the import whereas these modules have been developed separately)
bundle_copy - this is more like data export import module in that it appears to provide an all-in-one export import solution

Let me know your thoughts.

I do think your module has the advantage, since as well as being an all-in-one module, your documentation is very detailed and covers the pitfalls of deployment and also that you have a sponsor who presumably uses the module - nice to see a real live case study.

Thank you.

Comments

Comment #1

bailey86 CreditAttribution: bailey86 commented 2 October 2013 at 11:09

Hiya,

Thanks for the comments.

node_export

There is a key difference here:

https://drupal.org/node/1896384

Data Export Import (DEI) works hard to ensure that the nodes, terms and users end up with exactly the same ID's that they had when they were exported as when they are imported. That ticket refers to using UUID and fixing the issue for nodereference fields - but what if the reference to another node is buried in the text of a node? Also, what about backlinks to nodes which have their path set as something like http://www.example.com/node/123 - DEI was built for sites which had thousands of articles of different types and checking the text fields of all nodes was just not feasible.

So, I would say a key difference is that the nodes, terms, users on DEI end up with the same ID as when they were exported - and this is important in many cases.

I looked at using UUID - but felt that getting the ID numbers to match was more important - and that stopped users of DEI having to depend on another module which may have bugs introduced and cause problems.

Other than that it looks like the node_export module has had a lot of work carried out on it since I launched my module and probably for most use cases is fine.

feeds

I wanted a solution which output to a file - this would mean the exporting/importing could be staged and tested. Also, I felt it was easier to work with deployment scenarios where it is easier to move files around rather than linking up feeds.

Some of the sites which DEI was built for have data files which end up in the GB's size range. There were thousands of nodes and many of them had over 100MB of files attached. A feed type export/import could fail during the process and cause issues.

(BTW - I think node_export is an all-in-one solution and would not need to work with feeds).

bundle_copy

Bundle copy was released after DEI and as you say does a similar job. I'd be interested to know if it preserves ID numbers. I needed to build DEI for D6 initially as well as the sponsor was sticking to D6 at the time. DEI does have drush integration already - but it looks like bundle_copy has a patch for this.

Please note

If you are interested in how DEI is used for a dev a deployment process please check out https://github.com/SSVC/pullpush/wiki/About-Pullpush. The version1 branch is pretty much ready for full deployment as a V1.0 release. I should be working on it next week to get the release sorted.

Comment #2

therobyouknow CreditAttribution: therobyouknow commented 2 October 2013 at 13:28

Thank you very much bailey86 for your responding to my request. Definitely the information I was looking for.

I think the next step for me would be some experimentation with DEI (your module - data_export_import) and node_export. I favour yours out of these two for the retention of id numbers as you state.

I will also experiment with bundle_copy to seee how this compares. bundle_copy is part of Drupal 8 core (to assist with the Configuration Management Initiative (CMI) in D8). So I'd be curious to learn more about this module and why it was chosen for this purpose when there are other modules out there including yours. It may be that bundle_copy has no distinct advantages over the other modules or it might, rather it might have been chosen for other reasons, like building from scratch.

I'll close this ticket as I have got the information from you that I needed. Thank you very much.