On 22 Aug 2008, at 18:31, Andrew Jaquith wrote:
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)
Probably better to store these in a second database -- sort of how,
today, we allow you to use a different directory for attachments v.
wikipages.
I think I was more convinced by Florian; the repository should deal
with large items. This is also faster, since you don't need to do
two lookups for each object.
The ID associated with documents and revisions and whatnot should
be the unique ID number. That's classic normal-form stuff.
That was my initial reaction as well, but...
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
You'd rely on the user/group managers to tie the user identity back
to the IDs.
Here lies the problem - the JCR API does not know about this at all.
Once you say Session.exportSystemView(), you get *exactly* what is in
the repo. IDs and all.
Also, the JCR best-practice seems to be to stay away from IDs. If
you need to reference something, you should use a Path or Name
property to reference something intra-workspace.
http://wiki.apache.org/jackrabbit/DavidsModel
The approach I've seen elsewhere is to have a place where you map
the user IDs to the identifiers used on the "identity system of
record," whether that be LDAP, a relational database or whatnot.
This adds another level of indirection, of course, which sort of
sucks, but it's really just one more table that would get stored in
JCR.
Well, JCR does not exactly store tables, but it stores trees (with
arbitrary built-in references to make the graph circular, if you want
to).
We probably should keep the interfaces the way the are, but make
the default implementation ("JCRUserDatabase") use the JCR back-
end. Do we keep the XML and JDBC implementations for those who want
them, or maybe even get rid of them?
This is feasible, though then access to the Repository object needs
to be centralized somewhere (which means that it will leak upwards).
Migration, I think, is the key. We need to keep those around at
least to help in the conversion process.
Another problem with the UIDs is that then you can never really
delete someone's user account - but you must retain the mapping.
Otherwise you lose info about who changed what. This means that it
is also impossible to re-register using the same account name, even
though it has been "removed" (which necessarily isn't a bad thing,
since it could open up some security holes if you could guess a
deleted UID, and some pages still had ACLs referring to it). But
what this means that in practice, the login name becomes an unique
key throughout the wiki's life time, so you can't actually change the
UID - you really have to go and create a new account.
Dunno. There is a security problem brewing in allowing people to
change their account id's, because ACLs refer to those IDs, not the
UIDs. We should at least keep a trace of all old loginnames and
wikinames. Or just not allow changing them at all. I'm starting to
see Terry's point of view on all this...
/Janne
