durusmail: quixote-users: Draft of Quixote white paper
Draft of Quixote white paper
2003-06-25
2003-06-28
2003-06-30
2003-06-30
2003-06-30
2003-06-30
Draft of Quixote white paper
Jason Sibre
2003-06-30
> -----Original Message-----
> From: quixote-users-bounces@mems-exchange.org
> [mailto:quixote-users-bounces@mems-exchange.org]On Behalf Of Mark
> Bucciarelli
> Sent: Monday, June 30, 2003 1:19 PM
> To: quixote-users@mems-exchange.org
> Subject: Re: [Quixote-users] Draft of Quixote white paper
>
>
> On Friday 27 June 2003 9:24 pm, Jason Sibre wrote:
>
> > I recently addressed the issue you describe by using the underscore
> > (_) as a url placeholder indicating a new object.
>
> hmmm, i think this breaks the back button.
>

That's a good point, and one that I hadn't considered.  Your idea would work
well, but I don't like the fact that in a high traffic site, the same
timestamp could point to two different appointments that were created at the
same time.  This may not be an issue for something as time dependant as an
appointment, but in general, it could pose a problem.  I suppose another
alternative would be to generate a psuedo-GUID (globally unique id) each
time you render the "add new" button/link, and if they actually save it, it
becomes the ID of the entry...   I kinda dislike that approach however.  It
makes for long, ugly, hard-to-type id numbers.

I suppose this is also a problem with any method of adding a new entry to a
db of some sort, though...  You could have the same dilemma even if you used
an explicit '.../add' URL.  Hmm...  Need to check the docs/src... Perhaps
Quixote's form-token would be of some assistance here (serving as a
pseudo-guid in the storage layer.)

I guess you could still use an incremental integer type primary key, but
store the guid as well, and set up the _q_lookup to honor either one.
There's a bit of a penalty though:
In RDBMS terms:
        Either searching on an unindexed guid column,
        or maintaining two indices when one should suffice.
Or, in ODBMS terms:
        Either looping through all objects, and inspecting the guid attribute,
        or maintaining an index in the containing object

Same thing, I guess.


I've used the guid approach in a production app before (ASP - SQL Server)
and it worked...  But it really felt like a hack.

Hmm...

Jason


reply