2.18 Goals

[Bradley Baetz]

On 14 Sep 2002, MattyT wrote:

> On Sat, 2002-09-14 at 12:22, Bradley Baetz wrote:
> 
> > Only if they're actually renamed... You may was well say that renaming 
> > products breaks query urls. Whilst true, I don't think its relevent.
> 
> Right, but with charting, it's a *MAJOR* issue if you lose data.  With
> stored queries, you can fix your URLs.

Not if we (temporarily) require rerunning collectstats -regenerate, or
have the rename process rename the graph file...

> 
> > We could alllow both (and woudl have to, for back compatability)
> 
> It's possible, but I strongly question the notion that query URLs are an
> appropriate way to store stuff.  I think much more appropriate is a
> field ID/ID table.  Is there a way of having referential constraints to
> different tables from the one field (ID), depending on the values of
> other fields (field ID)?
>  

In theory, I think so, but I know that postgres doesn't implement that 
sort of stuff (check constrints involving other rows/columns/etc), mainly 
because its slow/not worth it.

If you just mean a way of representing the transitions rather than
requring the db to ensure that it holds, sure, there are proobably several
ways of doing it.

In practice, though, I still haven't been convinced that _totally generic
customised status transitions/etc are likely to be used by anyone. A
smaller subset (say, adding an extra state between two others) is probably
going to be more useful. There wil still be hard coded statues, such as
UNCONFIRMED, NEW, etc, or, rather, hard coded ids (the names could be
changable, in theory)

Bradley