Shorts, fixed decimals, and timespans as BSON primatives

[Justin Dearing]

Long story short I think all three should have a place in BSON. Here are my arguments:

short (Int 16): I know the way field names are stored throws this out the window, but the RDBMS DBA in me always looks to save 2 bytes in my integer columns.

fixed decimals: I don't know how the internals of these work, or if theres a standard implementation like floats. I do know that java and C# have a concept of a fixed decimal, and that I use them sometimes. I also know I don't want to store money in a float, and dividing an int by a hundred seems hackish.

TimeSpans: Pretty self explanatory. Sometimes I just need to store the time of day. Like fixed decimals, the problem is how to store them, and what the mongo driver will deserialize them to.

Justin

[Justin Dearing]

No comments on this?

[Dwight Merriman]

perhaps if we had arbitrary precision decimal type, shorts would
typically be quite short anyway (a number like 7 might only be 16 bits
in such a representation perhaps)

--
MongoSV is december 3rd

[Dwight Merriman]

timespan or time?

for timespan i would just say store the number of seconds of the span
as an integer

if i were coding in c++ or something I think i would be likely to do
something like:

{
unsigned visit_length_seconds;
}

rather than

{
TimeSpan visit_length;
}

although both make sense.

On Fri, Oct 22, 2010 at 9:17 AM, Justin Dearing <zipp...@gmail.com> wrote:

--
MongoSV is december 3rd

[Justin Dearing]

On Thu, Nov 11, 2010 at 11:58 AM, Dwight Merriman <dwi...@10gen.com> wrote:

timespan or time?

Well my current data model has a date field and several time fields. That being said, I'm storing the times in .NET TimeSpan objects (internally stored in an int representing seconds or microseconds I believe) . Also the Time property of a DateTime in .NET is stored as a timespan, thats you can assume will be less than or equal to 23:59:59.

So I guess storing it as seconds and letting the drivers figure out how to deserialize it makes the most sense.

[Justin Dearing]

On Thu, Nov 11, 2010 at 11:56 AM, Dwight Merriman <dwi...@10gen.com> wrote:

perhaps if we had arbitrary precision decimal type, shorts would
typically be quite short anyway (a number like 7 might only be 16 bits
in such a representation perhaps)

I guess that would work, but why not add both? Also, I'm a little concerned that a in the future mongo c-sharp driver might generate a class dynamically at runtime, and make decimals instead of shorts. That might cause some weird issues if you were using linq, Iron Python, etc where you have late binding and strong typing thanks to the dynamic language runtime. I don't know enough about the internals of that to say for sure though. Also, you might have similar issues in the JVM with something like scala.

So my question again, is why NOT add a short type?

Justin

[Dwight Merriman]

the main challenge is that 20 driver must then implement it.

--
MongoSV is december 3rd

[Dwight Merriman]

drivers

which can be done, it's just changes to BSON spec will need to be well
thought through and rare. it's far from perfect of course but if it
changes often it would be harder.

[Sergei Tulentsev]

And what about unsigned integers? Why aren't they in the spec?

[Dwight Merriman]

it's just a question of complexity and how many types i guess.

biggest request is for arbitrary precision decimal for money.

[Sergei Tulentsev]

Well, now I have to store UIDs as strings. Which, I guess, is somewhat less performant.

--
Best regards,
Sergei Tulentsev

[Gergely Nagy]

On Thu, Mar 17, 2011 at 17:12, Sergei Tulentsev
<sergei.t...@gmail.com> wrote:
> Well, now I have to store UIDs as strings. Which, I guess, is somewhat less
> performant.

You could store them as binary. The 0x80 subtype seems like a good
fit. (or 0x03, but there's not much documentation about that subtype)

--
|8]