incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <te...@net-frame.com>
Subject Re: author ids
Date Fri, 22 Aug 2008 12:54:51 GMT
I'm not really on top of the latest JSPWiki development thinking, but a
couple of thoughts occur to me, for what they're worth.

On attachments, the solution should perhaps anticipate a given
attachment might be referenced by more than one page (avoiding multiple
copies).  Moreover, there might be a good reason for simply referencing
an attachment (if the attachment is huge) rather than storing a separate
"attachment" object.

On author ids, I assume you mean user ids?  If so, I don't see how you
could avoid storing the id on the backend, since the id is the unique
identifier, not the name.  

What is the "repo model?"

BTW, Florian's comment brings another question to mind: if the users are
able to freely change their login (and other) names (because there's an
underlying, persistent unique id), what happens when different users
choose the same login name?  How does the login process distinguish
them?  Also, how are page ownerships handled in such situations (that
is, will we shift away from storing the page author's name and instead
use the unique id)?

Probably dumb questions, but here they are anyway.

On Fri, 2008-08-22 at 11:30 +0300, Janne Jalkanen wrote:

> Hi!
> 
> I'm currently designing the JCR model.  It is relatively  
> straightforward, except for two things:
> 
> 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)
> 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.
> 
> Opinions?
> 
> /Janne

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message