Quoting Graham Leggett <[EMAIL PROTECTED]>:
> Derek Atkins wrote:
>
>> Except SQLite is a requirement. If we can't support SQLite then
>> IMNSHO the project has failed. So by that, if we have to make
>> a workaround to get SQLite working, we should. Note that we can
>> always key the workaround code based on the version of gda we
>> find when we build gnucash.
>
> Then someone upgrades libgda, and gnucash silently breaks.
Umm.. I can't imagine ANY workaround that gnucash would perform
that would silently break with a gda upgrade. Worst case, a gda
update adds additional performance improvements but gnucash doesn't
get them because it's doing stuff "by hand". Also, one would hope
that some of these gda updates would also rev the so-number, or
change the gda_version() (assuming there is one).
> If there are issues with libgda support with sqlite, I suggest fixing
> the issues in libgda. Short term hacks lead to long term pain.
Oh, I'm all for getting gda fixed.. But there's a timing issue here.
How long does it take to:
1) get GDA to fix the problem
2) get a new GDA release
3) get the new GDA release into the distributions?
It's #2 and #3 in particular that can take the most amount of time, and
if that time isn't "less than a month" then we're in trouble.
> Regards,
> Graham
-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
