Bug 336843 - Attach files to Transactions

[Patrick]

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