Re: GDA: current status
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>> > > 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.
>> >
>> > Sure it could. Recurrence has:
>> >
>> > PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */
>> > PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */
>> > PERIOD_LAST_WEEKDAY, /* Also a phase. */
>> >
>> > I'm not exactly sure how you'd handle "last friday", except perhaps by
>> > "nth weekday" where n is -1 and the weekday of the first is friday.
>>
>> Actually, it's much simpler than that. "Last Friday of every month,
>> beginning yester day" is represented as {12/8/2006,
>> PERIOD_LAST_WEEKDAY, 1} (mult=2 would mean "last friday of every
>> _other_ month, etc.)
>
> For completeness, perhaps I should have also pointed out that it
> doesn't matter that 12/8/2006 wasn't the last Friday of the month. By
> specifying LAST_WEEKDAY, it will know you mean "Friday", and the first
> occurrence will be 12/29/2006. This is all documented in Recurrence.h
But what if the last MM/DD of a month falls on a Thursday, wouldn't
LAST WEEKDAY mean that? E.g. 11/30/06 is a Thursday. Wouldn't
LAST_WEEKDAY result in 11/30? How would I specify "last friday"
(which should result in 11/24)?
> -chris
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
> > > 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.
> >
> > Sure it could. Recurrence has:
> >
> > PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */
> > PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */
> > PERIOD_LAST_WEEKDAY, /* Also a phase. */
> >
> > I'm not exactly sure how you'd handle "last friday", except perhaps by
> > "nth weekday" where n is -1 and the weekday of the first is friday.
>
> Actually, it's much simpler than that. "Last Friday of every month,
> beginning yester day" is represented as {12/8/2006,
> PERIOD_LAST_WEEKDAY, 1} (mult=2 would mean "last friday of every
> _other_ month, etc.)
For completeness, perhaps I should have also pointed out that it
doesn't matter that 12/8/2006 wasn't the last Friday of the month. By
specifying LAST_WEEKDAY, it will know you mean "Friday", and the first
occurrence will be 12/29/2006. This is all documented in Recurrence.h
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
On Sat, Dec 09, 2006 at 06:37:55PM -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
> >> >> > - 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.
Looks may be misleading. Just because Recurrence has 3 members
instead of FreqSpec's 17 doesn't mean FreqSpec can represent more. In
fact, Recurrence is more general, both in the types of repetition it
can specify, and in that it also represents the starting date.
> >> >
> >> > 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.
Recurrences don't have guids, and have no relation to QofInstance or
QofEntity. They are not "engine objects". They are "data".
> >>
> >> Well, I think Freqspec is Recurrence + last-executed + number of
> >> executions.
Actually, not at all. Things like last-executed, number-executed,
start and end dates, and several more are all part of SX, not
FreqSpec.
It would be more accurate to say, conceptually,
Recurrence = FreqSpec + starting date.
> >> I dont really care how they get combined, but really there should be
> >> only one.
Phil, if you want to adapt FreqSpec + starting date from SX into
Recurrences, you're more than welcome, but 1) it's really outside the
scope of gda-dev, so I'd recommend another branch, and 2) be warned
that doing it right is a lot of work, (or it would already have been
done).
> >
> > 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.
>
> Sure it could. Recurrence has:
>
> PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */
> PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */
> PERIOD_LAST_WEEKDAY, /* Also a phase. */
>
> I'm not exactly sure how you'd handle "last friday", except perhaps by
> "nth weekday" where n is -1 and the weekday of the first is friday.
Actually, it's much simpler than that. "Last Friday of every month,
beginning yester day" is represented as {12/8/2006,
PERIOD_LAST_WEEKDAY, 1} (mult=2 would mean "last friday of every
_other_ month, etc.)
BTW, one difference between FreqSpec and Recurrence: FreqSpec can
actually represent an internally-linked tree-structure of nested
"composite" FreqSpecs. I have no idea why. It's a very inefficent
data structure, since only the "leaves" carry the data, and the
structure is meaningless. The Recurrence API handles this with a
GList of Recurrences. However, I believe it's an unused interface at
the moment.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
Quoting Phil Longstaff <[EMAIL PROTECTED]>: >> >> > - 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. Sure it could. Recurrence has: PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */ PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */ PERIOD_LAST_WEEKDAY, /* Also a phase. */ I'm not exactly sure how you'd handle "last friday", except perhaps by "nth weekday" where n is -1 and the weekday of the first is friday. >> 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. Well, you can test multi-user by running two instances of gnucash against the same database at the same time. :) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
On Sat, 2006-09-12 at 17:14 -0500, Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > 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 ___
Re: GDA: current status
Quoting Phil Longstaff <[EMAIL PROTECTED]>: > On Sat, 2006-09-12 at 13:19 -0500, Derek Atkins wrote: >> Quoting Phil Longstaff <[EMAIL PROTECTED]>: >> >> > - To avoid having the backend commit everything twice (because of the >> > Qof two phase commit protocol), saved objects are marked clean when >> > committed. To do this, I need to reach right into the QofInstance >> > structure and clear the dirty flag. There should be a better way to do >> > this. Note this also keeps the book from being marked dirty. Q: If a >> > db backend becomes the standard and xml is only for import/export, does >> > the concept of clean/dirty disappear? >> >> Yeah, with a DB backend the book should never be dirty. So, yeah, >> this is the right thing to do; you should clear the dirty bit when >> you commit. Perhaps there needs to be a qof_instance_clear_dirty(). > > 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. >> > - 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 backend has its own tables for objects which include db-related >> > info. Can these be merged with the engine object tables? >> >> I dont understand the question. Could you give a more specific example >> of what you mean? >> >> Keep in mind that the db backend certainly needs a table for its own >> configuration, so you can keep track of, e.g., the currenct schema version. >> This way we can easily update the database over time when we notice that >> the DB is at schema version X and gnucash is at schema version Y and X < Y.. >> Or we could report an error if X > Y... >> >> > Some engine tables don't exist (commodity), some have extra parameters, >> > some don't have all needed parameters, some don't have setters for every >> > parameter, some have an inappropriate setter, ... I've often wondered >> > if the engine object <-> backend interface should NOT use the standard >> > get/set APIs but should be more of a serialize/deserialize interface >> > where when an object is to be committed, the object's SaveYourself >> > method is called. This method grabs the backend and calls >> > SaveThisParameter multiple times. When loading, the object would be >> > malloc'ed and then its RestoreYourself method would be called. This >> > would call the backend's RestoreThisParameter. This would also solve >> > the problem of commits occuring while an object is being loaded (I have >> > a flag to catch these). >> >> The way the PG backend did this was to clear out the backend pointer >> during the load, so it didn't call back into the backend commit. But >> yeah, a Serialize(), Deserialize() "private" interface might be useful. >> >> > - 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
Re: GDA: current status
On Sat, 2006-09-12 at 13:19 -0500, Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > > - To avoid having the backend commit everything twice (because of the > > Qof two phase commit protocol), saved objects are marked clean when > > committed. To do this, I need to reach right into the QofInstance > > structure and clear the dirty flag. There should be a better way to do > > this. Note this also keeps the book from being marked dirty. Q: If a > > db backend becomes the standard and xml is only for import/export, does > > the concept of clean/dirty disappear? > > Yeah, with a DB backend the book should never be dirty. So, yeah, > this is the right thing to do; you should clear the dirty bit when > you commit. Perhaps there needs to be a qof_instance_clear_dirty(). 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. > > - 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. > > - The backend has its own tables for objects which include db-related > > info. Can these be merged with the engine object tables? > > I dont understand the question. Could you give a more specific example > of what you mean? > > Keep in mind that the db backend certainly needs a table for its own > configuration, so you can keep track of, e.g., the currenct schema version. > This way we can easily update the database over time when we notice that > the DB is at schema version X and gnucash is at schema version Y and X < Y.. > Or we could report an error if X > Y... > > > Some engine tables don't exist (commodity), some have extra parameters, > > some don't have all needed parameters, some don't have setters for every > > parameter, some have an inappropriate setter, ... I've often wondered > > if the engine object <-> backend interface should NOT use the standard > > get/set APIs but should be more of a serialize/deserialize interface > > where when an object is to be committed, the object's SaveYourself > > method is called. This method grabs the backend and calls > > SaveThisParameter multiple times. When loading, the object would be > > malloc'ed and then its RestoreYourself method would be called. This > > would call the backend's RestoreThisParameter. This would also solve > > the problem of commits occuring while an object is being loaded (I have > > a flag to catch these). > > The way the PG backend did this was to clear out the backend pointer > during the load, so it didn't call back into the backend commit. But > yeah, a Serialize(), Deserialize() "private" interface might be useful. > > > - 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. > > - 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) > > - 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 probab
Re: GDA: current status
On Sat, Dec 09, 2006 at 11:53:52AM -0500, Phil Longstaff wrote: > I've included a portion of the GDA_STATUS file which brings up some > questions: > > - 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?) No, recurrences don't need a table. They are smaller than one GDate + one gint. You should view them as an immediate data value, like GDate. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: current status
Quoting Phil Longstaff <[EMAIL PROTECTED]>: > - To avoid having the backend commit everything twice (because of the > Qof two phase commit protocol), saved objects are marked clean when > committed. To do this, I need to reach right into the QofInstance > structure and clear the dirty flag. There should be a better way to do > this. Note this also keeps the book from being marked dirty. Q: If a > db backend becomes the standard and xml is only for import/export, does > the concept of clean/dirty disappear? Yeah, with a DB backend the book should never be dirty. So, yeah, this is the right thing to do; you should clear the dirty bit when you commit. Perhaps there needs to be a qof_instance_clear_dirty(). > - 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. > - The backend has its own tables for objects which include db-related > info. Can these be merged with the engine object tables? I dont understand the question. Could you give a more specific example of what you mean? Keep in mind that the db backend certainly needs a table for its own configuration, so you can keep track of, e.g., the currenct schema version. This way we can easily update the database over time when we notice that the DB is at schema version X and gnucash is at schema version Y and X < Y.. Or we could report an error if X > Y... > Some engine tables don't exist (commodity), some have extra parameters, > some don't have all needed parameters, some don't have setters for every > parameter, some have an inappropriate setter, ... I've often wondered > if the engine object <-> backend interface should NOT use the standard > get/set APIs but should be more of a serialize/deserialize interface > where when an object is to be committed, the object's SaveYourself > method is called. This method grabs the backend and calls > SaveThisParameter multiple times. When loading, the object would be > malloc'ed and then its RestoreYourself method would be called. This > would call the backend's RestoreThisParameter. This would also solve > the problem of commits occuring while an object is being loaded (I have > a flag to catch these). The way the PG backend did this was to clear out the backend pointer during the load, so it didn't call back into the backend commit. But yeah, a Serialize(), Deserialize() "private" interface might be useful. > - 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. > - 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. > - 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. :( > Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GDA: current status
I've included a portion of the GDA_STATUS file which brings up some questions: - To avoid having the backend commit everything twice (because of the Qof two phase commit protocol), saved objects are marked clean when committed. To do this, I need to reach right into the QofInstance structure and clear the dirty flag. There should be a better way to do this. Note this also keeps the book from being marked dirty. Q: If a db backend becomes the standard and xml is only for import/export, does the concept of clean/dirty disappear? - 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?) - The backend has its own tables for objects which include db-related info. Can these be merged with the engine object tables? Some engine tables don't exist (commodity), some have extra parameters, some don't have all needed parameters, some don't have setters for every parameter, some have an inappropriate setter, ... I've often wondered if the engine object <-> backend interface should NOT use the standard get/set APIs but should be more of a serialize/deserialize interface where when an object is to be committed, the object's SaveYourself method is called. This method grabs the backend and calls SaveThisParameter multiple times. When loading, the object would be malloc'ed and then its RestoreYourself method would be called. This would call the backend's RestoreThisParameter. This would also solve the problem of commits occuring while an object is being loaded (I have a flag to catch these). - When a price is committed, the priceDB is also committed. Could there eventually be multiple priceDBs? The priceDB is currently ignored. - 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. - 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. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
