database tables for VuXML

[Oliver Eikemeier]

Jacques A. Vidrine wrote:

> On Sun, Aug 22, 2004 at 10:53:26PM +0200, Oliver Eikemeier wrote:
>> Jacques A. Vidrine wrote:
>>
>>> The `ranges' table perhaps looks erm interesting.  In this case,
>>> I encoded each package version number into four 32-bit integers.
>>> This allowed one to lookup an affected package completely in SQL.
>>> However, the encoding I used may now be incorrect in some ways, since
>>> pkg_install et al were recently changed to treat version numbers
>>> differently.
>>
>> I can just donate some code that converts version numbers into 
>> arbitrary
>> precision floting point numbers between zero and one.
>
> Sure, that's great if it covers all cases!  Floating point is limited
> to something like 64 bits, and I found version numbers that required
> almost 96 bits in the encoding I used (which I believe to be pretty
> tight).
>
>> An alternate (and
>> maybe easier to handle) form are hex strings which can simply compared
>> with strcmp.
>
> Definitely easier to handle (assuming everything is padded correctly).
> I found using integer comparisons was quite a bit faster, but this
> could be a micro-optimization.  Heck, I'm not convinced that the whole
> exercise of encoding version strings is not a micro-optimization :-)
> but it is fun and interesting.

Ok, I check if my prototypes still work. I'm not sure about the value of 
encoding version string (especially since you have to reencode 
everything again in case we make some additions), but if you have 
applications for it I won't be in the way.

>>>>    description     text                  not null,
>>
>> FWIIW, I would prefer to have a null description that is replaced by
>> some dummy text when rendering.
>>
>>>>    date_discovery  date                          ,
>>
>> That same here: don't assume a valid date (or map non-existing dates to
>> 1970-1-1). The reason is that I want to have a form of `quick' entries,
>> which are not fully reviewed.
>
> The current version of VuXML does not allow these to be null, and I it
> is probably good to reflect those constraints in the database.

Which means you possibly have to change the database description when 
upgrading.

>>> I think this is also easier to
>>> modify if we get new children of <package>, e.g. the <category> and
>>> <architecture> tags that are currently in the VuXML pre-1.2 DTD.
>>
>> Ehm, is the DTD somewhere available form review? And how about the
>> csh-style braces / <alternate><optional> tags suggested in
>> <http://docs.freebsd.org/cgi/mid.cgi?3AF421B2-F082-11D8-924A-00039312D914>
>> ?
>
> http://www.vuxml.org/dtd/vuxml-1/vuxml-pre12.dtd
> http://www.vuxml.org/dtd/vuxml-1/vuxml-model-pre12.mod
>
> The <category> is directly from the previous thread here, while
> <architecture> was recently added due to a conversation from last week
> that I thought was here ... but I don't see it in the archives, so I'm
> clearly mistaken about that.

<architecture> should be stuff like i386? I'm not sure that there are 
many applications for that. Usually the description is sufficient for 
those purposes. Or did you have something different in mind?

-Olver