Bug 336843 - Attach files to Transactions

[David Carlson]

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
> <christian at 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 at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20131113/37b85f9e/attachment.bin>