John Ralls writes:
> The policy that Derek declared a couple of weeks ago was that stable
> has to have added to it the ability to read dev's data. You're
> absolutely right that it shouldn't be able to write to a higher-rev's
> database; it should have to "save as".
I'm fine with this approach.
Am Montag, 3. Januar 2011 schrieb John Ralls:
> We need to re-think KVP entirely: It doesn't match up very well with the
> relational model.
Yes.
> The HBCI (online banking) setup, on the other hand, is contained entirely
> in a hierarchy of KVPs. This makes some amount of sense in XML, but it's
On Jan 3, 2011, at 9:25 AM, Jeff Kletsky wrote:
> John Ralls writes:
>
> "I think that the first step is to work through all of the code and make an
> ERD for the existing model, documenting the use and structure of KVP.
> (Pretend for the purpose of this exercise that every use of KVP is a se
iac. So I took something for it.
>
>
>
>
>
> From: Derek Atkins
> To: John Ralls
> Cc: Phil Longstaff ; Gnucash Devel Mailing List
>
> Sent: Mon, January 3, 2011 12:00:14 PM
> Subject: Re: Splitting the slots table
>
> John Ralls writes:
>
Longstaff ; Gnucash Devel Mailing List
Sent: Mon, January 3, 2011 12:00:14 PM
Subject: Re: Splitting the slots table
John Ralls writes:
> We need to re-think KVP entirely: It doesn't match up very well with
> the relational model.
Yeah. The KVP model works great for XML extensi
John Ralls writes:
"I think that the first step is to work through all of the code and make
an ERD for the existing model, documenting the use and structure of KVP.
(Pretend for the purpose of this exercise that every use of KVP is a
separate entity). Then we can normalize it into a good relat
John Ralls writes:
> We need to re-think KVP entirely: It doesn't match up very well with
> the relational model.
Yeah. The KVP model works great for XML extensibility. It does suck
for SQL extensibility.
As we move forward I think we need to think about both methods. We have
some requiremen
On Jan 2, 2011, at 2:34 PM, Phil Longstaff wrote:
> Just thinking ahead to conversion of the sql database to a true
> database, not just storage which is what it currently is.
>
> For most tables, we could add FOREIGN KEY constraints so that in the
> splits table, for example, the tx_guid which
Just thinking ahead to conversion of the sql database to a true
database, not just storage which is what it currently is.
For most tables, we could add FOREIGN KEY constraints so that in the
splits table, for example, the tx_guid which specifies the transaction
to which the split belongs must be a
