On 11/13/2013 7:09 PM, Patrick wrote: > Indeed, a very relevant question. I had thought about storing the file > itself in the database as a binary blob, but had concerns the db would > grow too large and cause other stability issues. Also, that wouldn't > work well with the XML back-end. > > I'm not sure how to ensure file availability, given any other program > or user outside of GNUCash could alter the filesystem (and, for > instance, delete the file.) That sounds intractable to me, assuming a > file:// url is used. Granted, there's nothing to guarantee an > http/https url will be around at next retrieval either. There is no > URL validation code in the input phase of the "Associate Location" > function - it'll just fail on retrieval. Same problem, different > space. > > Fundamentally, they are just links. But, to Derek's point, how then to > educate the user-base so as not to cause resentment when someone's > relative removes the linked files and the user blames GnuCash. > > In the end, I gave up pondering this further as I wasn't getting > anywhere. Definitely non-trivial. > > Patrick > > > On Wed, Nov 13, 2013 at 4:50 PM, Christian Stimming > <christ...@cstimming.de> wrote: >> This is a very relevant question - for the second iteration of this feature. >> In the first iteration, having the URL and/or softlink to the other file(s) >> is >> a great improvement over our previous situation. >> >> But the question of a multi-user access to the SQL database or a file on a >> network folder is indeed very relevant. It's the same sort of question as >> when >> the xml file is getting moved around on a computer or copied into a backup. >> We >> need to come up with a good solution on how to communicate to the user which >> part is getting backed up and which one is not. Or alternatively the linked >> files need to get strongly linked to the gnucash file and/or the SQL >> database. >> Seems quite non-trivial to me, though. >> >> But first I'm happy to see some progress in this feature at all. >> >> Regards, >> >> Christian > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >
If there is is a short warning about the fragility of external links within the program including a reference to a more thorough discussion in a help file, I think that users can decide for themselves whether to proceed. The discussion should include suggestions on ways to minimize risks by careful choice of storage locations for example, and how to construct references that are less likely to break if the files are moved to a different location. David C
0xDC7C8BF3.asc
Description: application/pgp-keys
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
