Community mailing list archives

Re: About Attachment File Location (again)

gunnar wagner
- 02/03/2015 05:18:13

On 2/3/2015 6:12 PM, David Arnold wrote:
<blockquote cite="" type="cite">
Cristophe has a very stringent and knowledgable line of thought. I also see *all* counter arguments invalidated. Unless the local NAS which isn't served over VPN, but strictly locally (by ethernet). But if it's a local setup, why not just have the Databse local as well and reduce entropy in the arguments. Here have been apples mixed with banana...

I'd recommend Large Objects as the default.
I though that (storing attachemnets in the db) is the default [v8] . but following this thread so far puts me in doubts a little
can someone clarify for dummies? Also if it is not the default and the recommendation would be to have attachments stored in the db ... how do you achieve that

<blockquote cite="" type="cite">
2015-02-03 3:42 GMT-05:00 Christophe Combelles <>:
Le 3 février 2015 04:08:15 EET, Phui Hock <> a écrit :
>I regret the best theorical solution is rarely the default in Odoo.
>is always dependent on the context and you should rather let people
>choose what
>is practical for them. Hopefully it's easy to migrate data from the
>storage to large objects.
>> LOBs:
>> - transcationals
>« transactional » means much more than a single word
>LOBs also :
>- are easier to setup
>- are more reliable
>- are replicable
>- are consistent (and not "eventually" consistent...)
>- can benefit from postgresql tools regarding backups, replication,
>> but
>> - bloat the replication stream
>You need to transfer the file anyway. At least, there is only one
>stream to
>manage. No need to set up an rsync or anything else.  Depending on the
>type of clients, saving binaries to database may be not acceptable at
>all. I have a client who is a media house and 90% of their files are
>several hundreds MB in size. One of their primary requirements is to
>have these files backup and accessible on their NAS-RAID. If the files
>are saved in the database, 

How do you keep a total sync between what is in the NAS and the ir.attachment metadata in the database?

>it would incur unnecessary database overhead
>every time the files need to be accessed or manipulated.

With the default 7.0 storage maybe, with the blob there are no more overhead than just reading a file from disk.

>For instance, we needed to generate previews and thumbnails for each of
>the known types. We also need to add watermark on-the-fly. These type
>of operations are easier and faster when files are saved on local

It seems easier in the first place (but not faster). It's easier to modify a file in the filesystem with a filesystem tool indeed, but it's harder to do it while keeping real sync with what is in the database anyway. And eventually I would bet it's easier in the long run to rely on the database security and transactionality.
It all depend on the importance you give to your data.

>Having these binaries saved on local filesystem also benefit from
>quicker streaming when served via web server such as nginx.

This is totally wrong, you can stream large blobs directly from the database do the browser, even PHP offers such features. And regarding small files they are supposed to be correctly cached anyway so they end up being never served by the filesystem nor the database.

>> - esay to browse by a human
>I'm not sure humans are good at browsing such SHA1 trees :
>│  ├── 57
>│  │  └── 57d4a8c7b652d6928d791c458cb04a246e3fb1ba
>│  ├── dc
>│  │  └── dcf00aacce882bbfd117c0277e514f829b4c5bf0
>│  └── ef
>│    └── ef2c882a36dbe90fc1e7e28d816ad1ac1464cfbb
>└── v8
>├── 35
>│  └── 358d08bafbecf102728c217bcc3eb0a24647443c
>├── 36
>While I agree these are not human readable, I don't think it is hard
>too to derive another filestore that overrides SHA1 filename with
>actual file name.

I believe something similar was done in old 6.1 or 7.0 modules that were abandonned due to their poor quality. Repoducing that with the filestore would make people believe they can use and modify it as real files which is wrong unfortunately, unless you maintain the sha1 filename and directory manually...

>Post to:

Post to:

Post to:


Gunnar Wagner | Iris Germanica Ltd. | JinQian Gong Lu 385, 8-201 | FengXian Qu, 201404 Shanghai | P.R. CHINA
+86 159 0094 1702 | +49 (0)176 7808 9090 | skype: professorgunrad |