Hi!
Some ideas come to my mind for the versioning issues...
* If no representation is defined for history in JCR, why did we choose
this "standard"? History is a major characteristic of Wiki...
* Is it possible to represent an "object in history" as an object in JCR?
In other words, to add paths information to designate an "historical
object" instead of a current object?
As one may not want to add constraints on names and paths (with
conventions like $$$X at the end of the name means version X: this
precludes names containing $$$), may be we can have a root level:
/current/ would be the root level for all current pages
/1/ would be all versions 1 of pages
/2/ all versions 2
...etc...
May be this is very bad in terms of access performances?
* Another solution would be to say that a "Wiki page" (or attachment) is
not a JCR leaf object but a JCR path (directory) containing "current"
for the current version, "1" for version 1, etc.
JCR would be (remain?) a kind of file system:
somebody would be kind enough to point me to a document explaining the
real advantage of JCR compared to a "regular" file system?
Is it only to remove the (sometime very deadly) differences between
Windows and Unix file system?
If true, a simple file name marshaller/unmarshaller would be enough,
isnt'it?
Have a nice w.e.
Christophe Dupriez
Janne Jalkanen (JIRA) a écrit :
[
https://issues.apache.org/jira/browse/JSPWIKI-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janne Jalkanen updated JSPWIKI-454:
-----------------------------------
Fix Version/s: (was: 2.8.2)
2.8.3
Bumped to 2.8.3.
Export tool
-----------
Key: JSPWIKI-454
URL: https://issues.apache.org/jira/browse/JSPWIKI-454
Project: JSPWiki
Issue Type: New Feature
Components: Core & storage
Reporter: Janne Jalkanen
Fix For: 2.8.3
In order to facilitate the move to a different backend in 3.0, and also
allowing people the choice of the 3.0 backend provider, we should have an
export tool which can export the old format repository to the JCR XML export
format (System View). This will also be useful in 3.0 for people who want to
have an implementation-independent database dump.
A couple of requirements:
* Must run with existing 2.8.x
* Must have an export functionality in the Admin UI
* Should have also a simple GUI
* Should have also a command-line interface
* Should also export version histories (though there is no standard
representation defined in JCR, we may have to invent our own.)
* May have built-in compression (the XML files are bound to be large)
(For 3.0 it then obviously becomes: add a tool which allows *importing* of such
XML document.)
