Jeff Johnson wrote:
>>> Or leave bad enuf alone for status quo ante "compatibility"?
>>
>> The big problem with the timestamps isn't the order, but
>> the lack of a timezone. Usually meaning "localtime", but...
>>
>
> Timezone really isn't too hard to solve in spewage:
>
> Everything in UTC always.
>
> and convert to local timezone however/whenever you please.
That would be better, just saw the code doing "localtime" ?
>> For the YAML timestamp, I think a missing timezone _might_
>> be interpreted as UTC which means the day could be off by one.
>>
>
> The "UTC always" enforcement can be done outside of YAML. And
> there's little lossage in the format choosing to always add UTC.
>
> Slicker would be to make "UTC always" a rule (it is since forever
> for all RPM timestamps, anything not in UTC is a bug), and reduce
> the markup redundancy, as well as the eye scratchiness, but ...
Much better, similar to choosing UTF-8 for the encoding.
> While there's all sorts of peripheral issues with date/time.
>
> I was more asking
>
> Should spewage attempt typing (like date/time) or just stick with integers?
>
> Lots of the peripheral issues disappear if its just an integer written
> into spewage.
Depends on the spewage, I suppose. For instance, JSON doesn't
have any specific "types" beyond strings/numbers/booleans/null
whereas YAML does... (like !!timestamp or !!binary and so on)
But it seems like the explicit type was not actually needed...
i.e. !!timestamp was overkill, YYYY-MM-DDThh:mm:ss is enough
That way it would work as JSON too, even if read as a string ?
On the other hand, it should sort just fine as a string too.
And one can append .microseconds to it, if it's ever needed.
> OTOH, integers are not very informative when read or grep'ed.
>
> I still don't have my own clear answer, and both your changes
> to YAML, and my changes to JSON are headed towards adding
> date/time types in the spewage, which is going to open
> up all the usual peripheral issues.
>
> Either integers/types "works". I 'spose that explicit times is
> easier to perceive as a "feature" ...
I think I'll change it back to strings (= drop the !!timestamp)
while keeping the :isodate format so it's still yaml-parseable.
Question:
The extra dbinstance column in the PRCO for mongo/json, is that
due to "reusing some" code from the sqlite/sql dumper perhaps ?
XML
<rpm:provides>
<rpm:entry name="rpmconstant" flags="EQ" epoch="1" ver="5.3.9"
rel="0.20110330.6"/>
<rpm:entry name="rpm" flags="EQ" epoch="1" ver="5.3.9"
rel="0.20110330.6"/>
</rpm:provides>
SQL
INSERT into provides values ('150994944', "rpmconstant", "EQ", "1", "5.3.9",
"0.20110330.6");
INSERT into provides values ('150994944', "rpm", "EQ", "1", "5.3.9",
"0.20110330.6");
YAML
Provides:
- rpmconstant = 1:5.3.9-0.20110330.6:2011.0
- rpm = 1:5.3.9-0.20110330.6:2011.0
JSON
Provides: [
[ '150994944', "rpmconstant", "EQ", "1", "5.3.9", "0.20110330.6" ],
[ '150994944', "rpm", "EQ", "1", "5.3.9", "0.20110330.6" ], ],
Shouldn't that DBINSTANCE be dumped somewhere too then, next to
the HDRID ? And what does the "Idtype" designate, in the YAML ?
Another question is whether "Id" should be changed into "_id",
or if that was just something specific to the Mongo database ?
--anders
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
