2006/10/30, Derek Atkins <[EMAIL PROTECTED]>:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
> >> Sorry, what I meant was that I didn't understand what you meant by
> >> "small add-on".. I don't know GDA well-enough to know what that means
> >> or how that would work.
> >>
> >> > Phil
> >
> > I ha
Phil Longstaff <[EMAIL PROTECTED]> writes:
>> Sorry, what I meant was that I didn't understand what you meant by
>> "small add-on".. I don't know GDA well-enough to know what that means
>> or how that would work.
>>
>> > Phil
>
> I haven't thought this through entirely, but these are my first
>
On Fri, 2006-10-27 at 12:56 -0400, Derek Atkins wrote:
> > Frequency specs are another example, because a compound fs can have
> fs's
> > as children.
>
> I dont know enough about FS to know whether they are also atomic
> objects like KVPs.
They are, in the composite case.
--
...jsled
http://a
On Sat, 2006-28-10 at 11:46 -0400, Derek Atkins wrote:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
> >> > Since the connection string will be db-specific, we may want a db core
> >> > built around libgda (see libgda vs libdbi e-mail) with a small add-on to
> >> > handle the connection string fo
Phil Longstaff <[EMAIL PROTECTED]> writes:
>> > Since the connection string will be db-specific, we may want a db core
>> > built around libgda (see libgda vs libdbi e-mail) with a small add-on to
>> > handle the connection string formatting and how guid's will be handled
>> > (as well as adding d
> I think we absolutely MUST support SQLite, and we SHOULD support
> MySQL and PG. Does someone want to volunteer to find the LCD
> features of those three DBs?
Here it is for SQLLite: http://www.sqlite.org/omitted.html
Main areas that may bite us (i owuld think):
-You can't drop a colum
On Fri, 2006-27-10 at 12:33 -0400, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
> >> I still don't understand why you want to do this. What does it buy
> >> us? It seems to add a LOT of complexity on the GnuCash side when
> >> building up SQL queries. Instead of just bein
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> OK. I was just giving an example. A better one which comes to mind is
> with kvp frames. A kvp frame can be a number, string, date, list, or
> subframe. Each element of a list is in itself, a kvp frame, so there's
> a hierarchy here (and Josh menti
Quoting "Jim C. Nasby" <[EMAIL PROTECTED]>:
> On Fri, Oct 27, 2006 at 11:51:50AM -0400, Derek Atkins wrote:
>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>
>> > You'd be better off creating a stored-procedure-based interface and
>> > having it enforce the semantics.
>>
>> Except not all DBs that
On Fri, Oct 27, 2006 at 11:51:50AM -0400, Derek Atkins wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > You'd be better off creating a stored-procedure-based interface and
> > having it enforce the semantics.
>
> Except not all DBs that we want to support have stored-procedures,
> so unf
On Fri, 2006-27-10 at 12:37 -0400, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
> > On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
> >
> >> I'm not sure what you mean by "cascade of DELETE operations".
> >> I think we CAN depend on the DB supporting transactions, but
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
>
>> I'm not sure what you mean by "cascade of DELETE operations".
>> I think we CAN depend on the DB supporting transactions, but it
>> might depend on what level of TXN support we want/need.
>
>
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>> I still don't understand why you want to do this. What does it buy
>> us? It seems to add a LOT of complexity on the GnuCash side when
>> building up SQL queries. Instead of just being able to print out
>> "$table.${object}_id='$guid'" we'd need a
On Fri, 2006-27-10 at 11:58 -0400, Derek Atkins wrote:
> I'm not sure what you mean by "cascade of DELETE operations".
> I think we CAN depend on the DB supporting transactions, but it
> might depend on what level of TXN support we want/need.
With foreign keys, you can specify what should happen
On Fri, 2006-27-10 at 12:01 -0400, Derek Atkins wrote:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
>
> >> I suppose we could use varchar; the guid has a fixed size so we know
> >> exactly how much space it requires. It's just an MD5 hash, so it's
> >> 128 bits, which is 16 bytes of binary or 32
Phil Longstaff <[EMAIL PROTECTED]> writes:
>> I suppose we could use varchar; the guid has a fixed size so we know
>> exactly how much space it requires. It's just an MD5 hash, so it's
>> 128 bits, which is 16 bytes of binary or 32 bytes of Hexstring.
>
> I am looking at having an int as the prim
Benoit Gregoire <[EMAIL PROTECTED]> writes:
> Depends what you use them for. Stored procedure used for additional
> referential integrity check are not a problem, and saved my ass more time
> than I can count. Stored procedures that write to the database and actually
> implement business logi
"Graham Leggett" <[EMAIL PROTECTED]> writes:
> Having said that I hope that the current XML file format be maintained as
> an export format - we check keep the thing in source control this way.
That's the plan.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Me
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> You'd be better off creating a stored-procedure-based interface and
> having it enforce the semantics.
Except not all DBs that we want to support have stored-procedures,
so unfortunately that's a non-starter.
-derek
--
Derek Atkins, SB '93 MI
Quoting "Jim C. Nasby" <[EMAIL PROTECTED]>:
> On Thu, Oct 26, 2006 at 03:33:37PM -0400, Derek Atkins wrote:
>> the list of requirements. Also, I dont think we can depend on stored
>> procedures; SQLite doesn't support them.
>
> Dumb question... why would someone want to run SQLite over the exist
On Fri, October 27, 2006 6:57 am, Jim C. Nasby wrote:
> Dumb question... why would someone want to run SQLite over the existing
> storage mechanism?
Because it's the same database engine for both local file and remote server?
Having said that I hope that the current XML file format be maintained
On Thu, Oct 26, 2006 at 03:33:37PM -0400, Derek Atkins wrote:
> the list of requirements. Also, I dont think we can depend on stored
> procedures; SQLite doesn't support them.
Dumb question... why would someone want to run SQLite over the existing
storage mechanism?
--
Jim C. Nasby, Database Ar
On Wed, Oct 25, 2006 at 08:39:18PM -0600, Mark Johnson wrote:
> Also, MySql has a bug which recently cost me some time. Foreign keys
> expressed as column constraints rather than table constraints are
> silently ignored! It has been reported multiple times (MySql bugs
> 11049, 7427, 4919, 1330
On Thu, Oct 26, 2006 at 05:49:36PM +0300, Ivars Grinbergs wrote:
> Derek Atkins wrote:
> > "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> >
> >
> >>> 1) We don't need an AccountType table. AccountTypes are not data,
> >>>they are encoded in the application. There's no reason to add
> >>>
Derek Atkins wrote:
>Mark Johnson <[EMAIL PROTECTED]> writes:
>
>
>
>>I may be getting a bit ahead of the play here, since you are talking
>>about design still, and I am thinking about implementation of it in a
>>MySql backend.
>>
>>I was recently doing some research on storing GUIDs in MySQL.
Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> I'd checked the SQLite 3, and it doesn't support foreing keys, but
> triggers. Then may be in the future, after finish the SQL backend
> support in GC, we can create a "gnc-data-server" a la Evolution, in
> order to read, insert and update some record
On Thu, 2006-10-26 at 15:33 -0400, Derek Atkins wrote:
> Quoting Benoit Gregoire <[EMAIL PROTECTED]>:
> >
> > While I fully understand your feeling, sharing with other programs is
> > probably
> > the primary reason why users want a SQL in the first place. Since we KNOW
> > people will use it thi
2006/10/26, Ivars Grinbergs <[EMAIL PROTECTED]>:
Derek Atkins wrote:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
>
>
>>> 1) We don't need an AccountType table. AccountTypes are not data,
>>>they are encoded in the application. There's no reason to add
>>>them to the database because
On Thursday 26 October 2006 15:51, Graham Leggett wrote:
> Benoit Gregoire wrote:
> > Yes you can (whith a "real" database). Checking that the sum of the
> > transaction's splits is 0 it trivial if all splits use the same
> > commodity, and mostly irrelevent if they don't. That's a really simple
Benoit Gregoire wrote:
Yes you can (whith a "real" database). Checking that the sum of the
transaction's splits is 0 it trivial if all splits use the same commodity,
and mostly irrelevent if they don't. That's a really simple stored
procedure.
And in the process, you restrict people to usi
> Actually, I think the primary reason users want SQL are to be able
> to run their own reports, multi-user, and automatic commits (saves
> on commit). I dont think that sharing the data read/write is high on
> the list of requirements. Also, I dont think we can depend on stored
> procedures; SQ
On Thursday 26 October 2006 10:49, Ivars Grinbergs wrote:
> Derek Atkins wrote:
> > "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> >>> 1) We don't need an AccountType table. AccountTypes are not data,
> >>>they are encoded in the application. There's no reason to add
> >>>them to the dat
On Thursday 26 October 2006 14:49, Phil Longstaff wrote:
> On Thu, 2006-26-10 at 09:53 -0400, Derek Atkins wrote:
> > Mark Johnson <[EMAIL PROTECTED]> writes:
> > > I may be getting a bit ahead of the play here, since you are talking
> > > about design still, and I am thinking about implementation
Quoting Benoit Gregoire <[EMAIL PROTECTED]>:
>> You can't get enough data integrity from the database. For example,
>> you cannot define the database in a way to enforce balanced transactions.
>
> Yes you can (whith a "real" database). Checking that the sum of the
> transaction's splits is 0 it
On Thursday 26 October 2006 10:02, Derek Atkins wrote:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> >> 1) We don't need an AccountType table. AccountTypes are not data,
> >>they are encoded in the application. There's no reason to add
> >>them to the database because they are constan
On Thu, 2006-26-10 at 09:53 -0400, Derek Atkins wrote:
> Mark Johnson <[EMAIL PROTECTED]> writes:
>
> > I may be getting a bit ahead of the play here, since you are talking
> > about design still, and I am thinking about implementation of it in a
> > MySql backend.
> >
> > I was recently doing s
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> I am looking at having an int as the primary key for references to a
> table. The GUID would be stored with the row as 4 ints (guid_1, guid_2,
> guid_3 and guid_4). If we need to search a lot by GUID, we could have
> an index which spans those 4 colu
Derek Atkins wrote:
> "Daniel Espinosa" <[EMAIL PROTECTED]> writes:
>
>
>>> 1) We don't need an AccountType table. AccountTypes are not data,
>>>they are encoded in the application. There's no reason to add
>>>them to the database because they are constants.
>>>
>>>
>> If useful
"Daniel Espinosa" <[EMAIL PROTECTED]> writes:
>> 1) We don't need an AccountType table. AccountTypes are not data,
>>they are encoded in the application. There's no reason to add
>>them to the database because they are constants.
>>
>
> If usefull if you want a strong data integrity done
"Daniel Espinosa" <[EMAIL PROTECTED]> writes:
> 2006/10/25, Josh Sled <[EMAIL PROTECTED]>:
>> On Wed, 2006-10-25 at 14:52 -0500, Daniel Espinosa wrote:
>> > Let me study this items, but at first, I could say that the way
>> > GnuCash handles the numeric values and representation, could be out
>> >
"Daniel Espinosa" <[EMAIL PROTECTED]> writes:
>> 1) Accounts: parent is not null. However, the top level accounts
>> (Assets, Liabilities, ...) don't have a parent. In addition, the parent
>> should be a foreign key reference back to the Accounts table.
>>
>
> parent could be set to NULL if the
Mark Johnson <[EMAIL PROTECTED]> writes:
> I may be getting a bit ahead of the play here, since you are talking
> about design still, and I am thinking about implementation of it in a
> MySql backend.
>
> I was recently doing some research on storing GUIDs in MySQL. There is
> no guid type in
On Wednesday 25 October 2006 15:57, Phil Longstaff wrote:
> I'd be happy to look at what you have. It seems to me that there will
> be enough differences that I won't be able to use much. I assume you
> used the Qt SQL classes rather than libgda or libdbi so I can't use much
> (if anything) of yo
Derek Atkins wrote:
>Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
>
>
>>On Wed, 2006-25-10 at 11:29 -0400, Derek Atkins wrote:
>>
>>
>>>Phil,
>>>
>>>Nice work so far. I've got a few comments.
>>>
>>>IDs:
>>>
>>>The ID should be the GUID. I don't think you can make that
>>>an int per-se; a
2006/10/25, Josh Sled <[EMAIL PROTECTED]>:
> On Wed, 2006-10-25 at 14:52 -0500, Daniel Espinosa wrote:
> > Let me study this items, but at first, I could say that the way
> > GnuCash handles the numeric values and representation, could be out
> > the scope of the schema becouse it will show how the
2006/10/25, Derek Atkins <[EMAIL PROTECTED]>:
Hi,
A few more comments (my previous comments directly to Phil still
apply). I just looked at the Dia drawings, and I've got a few
more comments. Note that you didn't send out an updated doc, so
these comments are based on the original version:
1
On Wed, 2006-10-25 at 14:52 -0500, Daniel Espinosa wrote:
> Let me study this items, but at first, I could say that the way
> GnuCash handles the numeric values and representation, could be out
> the scope of the schema becouse it will show how the values are stored
> in the database and how they a
Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> Consider that may in the future GnuCash and KMyMoney, could share the
> same DB and give diferent GUI, why don't work together and define a
> solid DB storage structure for the end user (and leave him to use the
> GUI he wants, even a web one).
I don
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> On Wed, 2006-25-10 at 11:29 -0400, Derek Atkins wrote:
>> Phil,
>>
>> Nice work so far. I've got a few comments.
>>
>> IDs:
>>
>> The ID should be the GUID. I don't think you can make that
>> an int per-se; although it IS a 128-bit number. I don't t
2006/10/25, Phil Longstaff <[EMAIL PROTECTED]>:
> On Wed, 2006-25-10 at 14:12 +0100, Tony Bloomfield wrote:
> > As designer of the SQL backend for a rival package (KMyMoney), I'd be happy
> > to
> > swap ideas, etc. There's not a great deal of difference between the two
> > products, except that K
On Wed, 2006-25-10 at 11:29 -0400, Derek Atkins wrote:
> Phil,
>
> Nice work so far. I've got a few comments.
>
> IDs:
>
> The ID should be the GUID. I don't think you can make that
> an int per-se; although it IS a 128-bit number. I don't think the
> databases have 128-bit integer data types
2006/10/24, Phil Longstaff <[EMAIL PROTECTED]>:
> On Mon, 2006-23-10 at 22:38 -0400, Josh Sled wrote:
> > It'll probably be the case that the SQL DDL statements will be easier to
> > work with than these pictures. Just plain text like...
> >
> > CREATE TABLE accounts
> > (
> > id int
2006/10/23, Josh Sled <[EMAIL PROTECTED]>:
On Mon, 2006-10-23 at 17:14 -0500, Daniel Espinosa wrote:
> Attached you'll find a DataBase Schema for GnuCash.
>
> This is in order to bigin the development to support DB backend (and
> replase the actual file one).
I agree with Phil's comments. Here'
Hi,
A few more comments (my previous comments directly to Phil still
apply). I just looked at the Dia drawings, and I've got a few
more comments. Note that you didn't send out an updated doc, so
these comments are based on the original version:
1) We don't need an AccountType table. AccountTy
I'll response message by message, then this is for this:
2006/10/23, Phil Longstaff <[EMAIL PROTECTED]>:
> On Mon, 2006-23-10 at 17:14 -0500, Daniel Espinosa wrote:
> > Attached you'll find a DataBase Schema for GnuCash.
> >
> > This is in order to bigin the development to support DB backend (and
Phil,
Nice work so far. I've got a few comments.
IDs:
The ID should be the GUID. I don't think you can make that
an int per-se; although it IS a 128-bit number. I don't think the
databases have 128-bit integer data types.
LOTS:
You probably want a Lots table. The table would have the defin
On Wed, 2006-25-10 at 14:12 +0100, Tony Bloomfield wrote:
> As designer of the SQL backend for a rival package (KMyMoney), I'd be happy
> to
> swap ideas, etc. There's not a great deal of difference between the two
> products, except that KMM does not really support small business.
>
> Anyhow,
As designer of the SQL backend for a rival package (KMyMoney), I'd be happy to
swap ideas, etc. There's not a great deal of difference between the two
products, except that KMM does not really support small business.
Anyhow, let me know if you'd like me to post the DDL, usage description, etc.
On Mon, 2006-23-10 at 22:38 -0400, Josh Sled wrote:
> It'll probably be the case that the SQL DDL statements will be easier to
> work with than these pictures. Just plain text like...
>
> CREATE TABLE accounts
> (
> id int NOT NULL,
> name String,
> parent int NOT NULL,
On Mon, 2006-10-23 at 17:14 -0500, Daniel Espinosa wrote:
> Attached you'll find a DataBase Schema for GnuCash.
>
> This is in order to bigin the development to support DB backend (and
> replase the actual file one).
I agree with Phil's comments. Here's some more:
Simple conventions on things l
On Mon, 2006-23-10 at 17:14 -0500, Daniel Espinosa wrote:
> Attached you'll find a DataBase Schema for GnuCash.
>
> This is in order to bigin the development to support DB backend (and
> replase the actual file one).
>
> I added a Inventory Table (or Class) in wich you can have the
> merchandise
Attached you'll find a DataBase Schema for GnuCash.
This is in order to bigin the development to support DB backend (and
replase the actual file one).
I added a Inventory Table (or Class) in wich you can have the
merchandise in a small business like a small store.
2006/10/23, Daniel Espinosa <[
2006/10/22, Josh Sled <[EMAIL PROTECTED]>:
> On Sat, 2006-10-21 at 22:56 -0400, Phil Longstaff wrote:
> > 1) target SQLite, PostgreSQL or MySQL directly in a QOF back end, or
> > 2) target libdbi or another such layer (how many data layers do we
> > want?) which would give us all three (SQList, Pos
Derek Atkins wrote:
>Phil,
>
>Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
>
>
>
...
>>Is there any current vision for database use? Of the 3 databases I've
>>listed, I've only used MySQL. SQLite would remove the need for an
>>external db server, though embedded MySQL would also remove thi
Quoting Graham Leggett <[EMAIL PROTECTED]>:
> Phil Longstaff wrote:
>
>> 1) target SQLite, PostgreSQL or MySQL directly in a QOF back end, or
>> 2) target libdbi or another such layer (how many data layers do we
>> want?) which would give us all three (SQList, PostgreSQL and MySQL
>> immediately),
Phil,
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> I have some time available for development (was laid off about a week
> ago :-( ) and thought that a good project to spend some time on would be
> an SQL backend for GC2/QOF. I know that a while ago, someone named
> Matthew V (?) was workin
On Sat, 2006-10-21 at 22:56 -0400, Phil Longstaff wrote:
> 1) target SQLite, PostgreSQL or MySQL directly in a QOF back end, or
> 2) target libdbi or another such layer (how many data layers do we
> want?) which would give us all three (SQList, PostgreSQL and MySQL
> immediately), or
> 3) target OD
Phil Longstaff wrote:
1) target SQLite, PostgreSQL or MySQL directly in a QOF back end, or
2) target libdbi or another such layer (how many data layers do we
want?) which would give us all three (SQList, PostgreSQL and MySQL
immediately), or
3) target ODBC using iODBC which would give us even mo
I have some time available for development (was laid off about a week
ago :-( ) and thought that a good project to spend some time on would be
an SQL backend for GC2/QOF. I know that a while ago, someone named
Matthew V (?) was working on something in the GC 1.X series, but I
haven't seen his
69 matches
Mail list logo
