incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Holeczek <>
Subject Re: author ids
Date Fri, 22 Aug 2008 10:51:12 GMT
Hallo Janne,

> 1) storing of attachments (I haven't figured out yet whether it's
> better to store them in a separate workspace, because then you can
> leverage faster local filesystems instead of putting really big
> binaries into the database)

I think implementation details shouldn't affect the data model.

Attachments conceptually belong to specific (sub)pages, so they should
be saved there. How and where they're saved should be an
implementation detail of the JCR implementation.

Apache Jackrabbit provides a DataStore [1] as a solution for this
problem. It automatically and transparently saves objects greater than
a given length in the DataStore which is e.g. a file system.

> 2) and more importantly, author names.

> Now, we have in 2.8 a way to uniquely identify an author by an id  
> number, allowing for author name changes.  This is quite fine, but  
> I'm now unsure what should be stored into the backend.

> Storing the id alone brings in the following problems:
> * Imports/exports break, since the repo model would only export the  
> ID, and there would be no binding of that to real identity
> * Since the id=>identity mapping is not done in the JCR backend,
> every getAuthor() (w/out cache) would cause multiple DB accesses.
> * numeric ids are not necessarily available from the userdb backend  
> (e.g. if you use LDAP or something similar), so they would be  
> internal only - which means that if you export or access the content  
> via other means, you would not be able to figure out the user.

> One possibility would of course to be and ditch any custom User/ 
> GroupDatabases and make them use the JCR backend, too.  But that will
> tie them together for better or worse.

> Another possibility would be to store both the id *and* the WikiName.

What about storing *only* the WikiName?

AFAIK, one constraint is that WikiNames are unique, so an author name
in the wiki pages would be unique, too. When changing a WikiName, all
pages would have to be processed, which is a quite expensive
operation, of course. But I think it's also a quite rare operation.
Also, no additional calls would have to be made during normal
operations like loading a page a.s.o.

Another thing which isn't quite straightforward is i18n of pages and
page names. Is this out of scope or did you think about it, too?


[1] Jackrabbit DataStore:

View raw message