what does exporting all cards to a text file look like?

---

Output could be done via XML, or JSON, then rendered via css addons (this could also allow PDF export, printable page export, etc)

  --Sam Rose.....Mon Aug 03 14:59:57 -0700 2009

---

plain text output from Basic and other text cards could be the wiki-markup we see when editing, and similarly for other cardtypes (lists of [[]]s for Pointers, HTML in HTML cards, nothing for images?)

  --John Abbe.....Fri Feb 19 03:35:05 -0800 2010

---

Oh, I suspect we'd probably start by dumping the content as it's stored, which is HTML in the case of Basic cards. The bigger question is how to contain the content.

  --Ethan McCutchen.....Fri Feb 19 08:32:33 -0800 2010

---

I'm increasingly convinced that this should be just another WQL output. Would need to be optimized for big dumps.

  --Ethan McCutchen.....Thu Jan 06 10:22:13 -0800 2011

---

It doesn't matter as much what the format is as it does that you can load them. Formatting the export as a console script that you can run to reload the data would work. Or XML, json, etc. and having matching import functions.

 

Minimally, you need to get current content, name and type for each card in the set. The other issue is ordering, do you do in on output, or input. In other words, do I output them in "dependents first" order so at least the cardtypes and owners or loaded before the cards that reference them.

 

Ok, well 'author' isn't part of the "name, type, value" minimal set, and so we may want to consider both this kind of "content export" vs. one the preserves all the meta-data, and likewise consider the importing use cases for the same.

  --Gerry Gleason.....Thu Jan 06 13:21:29 -0800 2011

---

So, add HTML view?

  --John Abbe.....Tue Jan 11 18:56:45 -0800 2011

---

Regarding dependency, circular references are possible in Wagn, so I wouldn't worry about it. Maybe in creation order?

 

Ideally I'd be able to export enough information to clone the database. Then people can optionally be able to keep or throw away card history/changes, author, and other metadata. Important to choose good defaults here.

  --John Abbe.....Tue Jan 11 19:06:37 -0800 2011

---

Yes, creation order. In most cases, you are right that the order shouldn't matter, missing links just get filled in with real cards, but some things like cardtypes and users may be different. The cards have to exist first to have a id and extension.

 

And I totally agree on exporting all the metadata so that the consumer of the data can use whatever they need.

  --Gerry Gleason.....Thu Jan 13 04:29:56 -0800 2011

---

A simple one-card case is ticketed as add csv view, and exchanging groups of cards between Wagns as add ability to pass hands of cards between Wagns.

  --John Abbe.....Wed Feb 16 12:09:04 -0800 2011

---

See also improve JSON rendering

  --Ethan McCutchen.....2012-09-28 16:30:51 +0000

---

1. What's the thought on when we;d like to have this implemented? (No specific need, just curious.)

 

2. Is this ticket focused on an export format that would be readable as is by Wagn only, which could then be transformed into other formats as needed? (With actually implementing those transformations as other tickets?)

  --John Abbe.....2013-03-20

---

1. Don't know. Not a 2.0 priority (though funding opportunities could change that)

2. Well, whatever it is would be in a standard data format (xml, json, csv, etc), so other tools could read and transform it.

 

There's not a lot of specification, nor is there much demand. I'm changing this to an Idea until we have more clarity.

 

One very simple use case would be to dump data from a Wagn site and use it to create a copy. The best test case would probably go from mysql to postgres or vice versa (going from mysql to mysql can already be done with a mysql data dump). The only time there was really a use case for this was when we were migrating servers.

 

There are lots of other very valuable use cases, but they are more involved, because they involve merges of one sort or another, eg:

 

1. importing from wikimedia, drupal, wordpress, etc

2. sharing little pieces of Wagn code (see DeckoSystems

3. exporting to other useful formats.

  --Ethan McCutchen.....2013-03-20 20:07:07 +0000

---

4. Importing from a spreadsheet (or any one-table database)

  --John Abbe.....2013-03-22 00:04:09 +0000