[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for LedgerSMB 1.5: Move to Pg 9.2 and use JSON for extended attributes
- Subject: Re: Proposal for LedgerSMB 1.5: Move to Pg 9.2 and use JSON for extended attributes
- From: John Locke <..hidden..>
- Date: Mon, 24 Dec 2012 09:50:31 -0800
On 09/17/2012 02:44 AM, Chris Travers wrote:
I have been thinking about the way we handle customizations in old
code vs new code where new fields need to be added. Currently adding
these for old code is pretty easy, but adding them for new code is a
little more problematic. We have two options going forward:
1) We can move to Pg 9.1 as the required version and add a dependency
on hstore. An hstore field can be attached to every major object
type, retrieved and submitted with the stored procs, etc. We could
actually also do the same in 8.4 using a text field to store JSON but
the db would be unable to validate it.
2) We can move to Pg 9.2 as a required version and use JSON in the
same way. We wouldn't need to depend, out of the box, on plv8js or
any other extensions but customizations that might use this would be
Does this mean that the proposal to use 9.2 can be supported in 9.1 with
hstore? If so, +1. I'm fine with installing extensions like this.
Just want to point out that Ubuntu 12.04 LTS ships with 9.1 -- and at
least in my business, that's going to be the preferred platform for the
next 18 months or so (and I'm sure I'm not alone). Forcing an upgrade to
9.2 would complicate things...
So if the proposal is for #2 without supporting #1, -1.
3) We could continue with 8.4 and store as XML. This would give us
validation and xpath functions. There is more XML functionality in
PostgreSQL (any version) than there is JSON functionality.
My preference currently is to move to JSON since it is a little easier
to reliably convert to/from Perl data structures, and would be a
little easier in other languages, probably, too. What does everyone
We continue to do fresh API work on new projects, and we still very much
like/prefer JSON in general, if it meets the needs. However, we have run
into a couple situations recently where the extra validation and schema
tools available for XML have proven beneficial.
If these are not necessary in this case, I'm all for using JSON.