Re: Crossserver ops and lock token swapping.

Yaron Goland (Exchange) wrote:
> 
> One of the first lessons learned years ago in the database world is to
> absolutely never put any useful information into an identifier. It always
> bites you.

Forgive me if my jaw hits the floor.

Database tables use column values all the time for primary keys. You do
*not* have to always create an "id" column. Yes, you usually do when you
have various foreign-key relationships (as part of the process of
normalizing your database design), but there is *nothing* in database
relational theory that requires the addition of an extra column simply
to refer to rows in a database.

A URI is a unique value which contains useful information. If I have no
foreign key relationships or I don't want to normalize my tables, then
why do I have to munge that into something else? That's bunk. Useful
info can definitely be part of an identifier. I can cite examples :-)

> As such servers that put useful information into their lock
> tokens are basically guaranteed to be badly written. In this case the first
> manifestation of this "brokenness" will be when they try to coordinate with
> other servers.

I disagree with your assertion. Let's say that I have a repository
(table) with two columns: a database-assigned unique serial number
("id"), and a binary blob. I use this table to store the resources on my
server. When I generate a locktoken, I want that token to specify the
resource's "id" for efficiency purposes.

If the WebDAV spec does not allow that, then it is broken. As it is
currently written, it *does*, but it seems like you're trying to say
that all locktokens should be uniform, regardless of repository. NFW.

I don't see how you can assert that my server would be "badly written"
because of this feature. What makes you believe that? I see no support
for your position.

Coordinating with other servers is beyond the scope of WebDAV. Further,
when/if this server-server communication begins to be designed, then
you're going to need to deal with different locktoken designs simply
because servers are going to want to have opaque/private locktokens. I
know that I want custom locktokens.

> While it is true that we can hack up the protocol to make it support
> allowing the lock token to be changed on a request by request basis this is
> an abysmally bad idea.
> [snip: discussion of why changing tokens is bad]

Excellent point! I agree with you here. That leads me to believe that
locks MUST NOT move with the resource since the Destination may not
support the transfer of the locktoken (heck, what happens if the
Destination doesn't support locking!).

However, I still disagree on your notion that locktokens cannot be
defined by the server (to include useful info). And I *really* disagree
with your (unsupported) view that this implies the server is badly
written.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Received on Friday, 10 September 1999 20:18:38 UTC