Thanks again, Ken.
On Thursday, September 4, 2014 2:14:25 PM UTC-5, Ken Barber wrote:
>
> > Thanks, Ken. Could you devote a few words to how PuppetDB chooses which
> of
> > those alternative columns to use for any particular value, and how it
> > afterward tracks which one has been used?
>
>
> Thanks, Ken. Could you devote a few words to how PuppetDB chooses which of
> those alternative columns to use for any particular value, and how it
> afterward tracks which one has been used?
So PuppetDB, in particular fact-contents, and the way it stores leaf
values makes a decision using a ver
On Thursday, September 4, 2014 9:40:43 AM UTC-5, Ken Barber wrote:
>
> >
> > Every Puppet value is potentially a Big now. What new cost is involved?
> > I'm having trouble seeing how a database can deal efficiently with
> Puppet's
> > current implicit typing anyway, Big values notwithstandin
> I would think if we had transport encoding issues (like mspack not
> supporting a larger type natively) we could decode before we store I
> guess. Thats an alternative. It means traversing the tree to find
> these cases and modifying them on the float perhaps. Things like
> zipper in clojure make
>> So right now, we have alternating native postgresql columns for the
>> bare types: text, biginteger, boolean, double precision. This provides
>> us with the ability to use the most optimal index for the type, and of
>> course avoid storing any more then we need to. As I mentioned at the
>> top o
On 2014-04-09 16:40, Ken Barber wrote:
2) Why would allowing one or both of the Bigs prevent Number from being
allowed as a serializable type?
Not sure I said that. The problem is that if something is potentially
Big... then a database must be prepared to deal with it and it has a
high cost.
>> > 2) Why would allowing one or both of the Bigs prevent Number from being
>> > allowed as a serializable type?
>> >
>> Not sure I said that. The problem is that if something is potentially
>> Big... then a database must be prepared to deal with it and it has a
>> high cost.
>
>
>
> Every Puppet
On 2014-04-09 24:35, John Bollinger wrote:
On Wednesday, September 3, 2014 12:40:45 PM UTC-5, henrik lindberg wrote:
On 2014-02-09 22:23, John Bollinger wrote:
>
>
> On Monday, September 1, 2014 3:55:03 AM UTC-5, henrik lindberg
wrote:
>
> Hi,
> Re
On Wednesday, September 3, 2014 12:40:45 PM UTC-5, henrik lindberg wrote:
>
> On 2014-02-09 22:23, John Bollinger wrote:
> >
> >
> > On Monday, September 1, 2014 3:55:03 AM UTC-5, henrik lindberg wrote:
> >
> > Hi,
> > Recently I have been looking into serialization of various kinds
On 2014-02-09 22:23, John Bollinger wrote:
On Monday, September 1, 2014 3:55:03 AM UTC-5, henrik lindberg wrote:
Hi,
Recently I have been looking into serialization of various kinds, and
the issue of how we represent and serialize/deserialize numbers have
come up.
[...]
On Monday, September 1, 2014 3:55:03 AM UTC-5, henrik lindberg wrote:
>
> Hi,
> Recently I have been looking into serialization of various kinds, and
> the issue of how we represent and serialize/deserialize numbers have
> come up.
>
>
[...]
>
> Proposal
>
> I would like to cap
On 2014-02-09 19:12, Ken Barber wrote:
TL;DR - I want to specify the max values of integers and floats in the
puppet language for a number of reasons. Skip the background part
to get to "Questions and Proposal" if you are already familiar with
serialization formats, and issues regarding numeric r
On 2014-02-09 8:39, markus wrote:
Most serialization formats can simply not deal with > 64 bit values as
regular numbers. They may do horrible things like truncation, or use
the max/min value if a value is too big, or for floating point
drastically lose precision.
Eh. It's not that the seria
On 2014-01-09 19:15, Trevor Vaughan wrote:
TL;DR; BigInteger/BigDecimal is the "right" thing to do, otherwise cap
at the client/server floor.
I have a few thoughts here:
1) I don't like losing precision in any case so a cap makes sense (maybe)
2) If you do cap, would you not want to cap to the
14 matches
Mail list logo
