GDA: current status

[Phil Longstaff]

On Sat, 2006-09-12 at 17:14 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
> > My question about "should the concept of clean/dirty disappear" is to
> > raise it as an architectural change.  Should these be put into bugzilla?
> > If so, I will.
> 
> Oh, no, architecturally this should stay, because it's still reasonable
> to have the concept of full-save backends.  Besides, if this change
> were to happen it's still a few major releases out, so no point in
> thinking about it now.  We wouldn't remove the XML Backend for
> at least two releases after SQLite support gets in, so you can't
> NOT handle the dirty-bit.

OK

> >> > - Recurrences are currently only used by budgets, and recurrence
> >> > save/restore is included in the budget save/restore code.  If
> >> > recurrences will eventually be used elsewhere in GC, recurrence
> >> > save/restore code may need to be split out on its own (separate
> >> > recurrences table?)
> >>
> >> *GRR*  I knew this was going to be a problem.  I really should have
> >> been more insistant that Chris fix this BEFORE 1.8.   Recurrence and
> >> Freqspec should merge into a single data object.  We don't need both,
> >> and having both just duplicates code and confuses the data model.  They
> >> perform essentially the same functions and even do it in fairly similar
> >> ways.
> >>
> >> It's unfortunate that they are still two separate objects.
> >>
> >> For the DB backend I'd really like there to be only one (probably
> >> Recurrence).  And yes, it should be its own table.
> >
> > I think Recurrence is a subset of FreqSpec i.e. FreqSpec can represent a
> > lot more than a Recurrence can.  In any case, I will have 1 table and
> > the back end will convert to that 1 table.  My choice (given my limited
> > knowledge) is to use FreqSpec because it is a more general mechanism.
> > If that generality is not desired, feel free to dictate otherwise.
> >
> > I just saw Chris's response that Recurrences don't need their own table.
> > I'll let Derek and Chris hash out the larger architectural issues on
> > this one.
> 
> Well, I think Freqspec is Recurrence + last-executed + number of executions.
> I dont really care how they get combined, but really there should be
> only one.

The thing about FreqSpec is that they don't look like they need to be
evenly spaced.  I don't know why you would not do that, but you might
want a FreqSpec to be "last friday of every month" or "15th and 30th of
every month" which Recurrence wouldn't handle.

> >
> >> > - When a price is committed, the priceDB is also committed.  Could there
> >> > eventually be multiple priceDBs?  The priceDB is currently ignored.
> >>
> >> The PriceDB is just the collection of Prices.  I dont think we ever
> >> have multiple PriceDBs.
> >
> > Is there any reason it is a first class object and not just a
> > qof_collection?  I don't feel the urge to change it now, so I can log it
> > in bugzilla.
> 
> Um..  I dont know why offhand; I'd have to look at the code and see what
> the PriceDB actually has.   I dont think we ever have two PriceDBs in
> a book, nor do I know why we'd ever want multiple PriceDBs in a book.
> 
> >> > - Multiple books?  The old postgres backend had a books table.  If the
> >> > new db should have one, accounts (and other objects) should have a book
> >> > guid field.
> >>
> >> *ponders*  Might not be a bad idea to do this now.
> >
> > OK.  I'll add a books table (probably just a guid and a lock)
> 
> Not sure why you'd need a lock...  But I could imagine this as a way
> to handle multiple periods..  Each transaction would belong to a specific
> period (Book)....

I guess I'm looking at a phased approach.  Multi-user operation is not
my itch and I am not really set up to test multi-user.  I haven't put in
transaction use, though I guess that is needed even in a single-user
case to help ensure db consistency.  I'd use a lock to just replicate
the current use of a lock file so that if two people are using the same
gnucash db, the second user would be warned of the first user's
presence.  Ultimately, it wouldn't be needed.

> >> > - If I try to "Save As" and type a url (e.g. gda://xxx), this gets
> >> > converted to file:///home/phil/.../gda%3F%2A%2Axxx.  (I don't remember
> >> > the % escapes exactly, but you get the picture).  I tried adding
> >> > gtk_file_chooser_set_local_only( file_box, FALSE) but that didn't help.
> >>
> >> I think it's a bug in the File Chooser..   We probably should revert back
> >> to the GNC File Select dialog we used to have.  This bug has already
> >> been reported against 2.0 because you cannot save as to postgres either.
> >>
> >> This is.... unfortunate.  :(
> >
> > I'm going to leave this for now.
> 
> Well, we'll need some way to type in relatively-arbitrary URLs..

I agree.  I said "for now".  If anyone else wants to resurrect the old
File Select dialog or fix the File Chooser, please be my guest.

Phil