openerp-connector-community team mailing list archive
-
openerp-connector-community team
-
Mailing list archive
-
Message #00465
Re: Storing Images
Hi Markus,
2014-06-19 17:06 GMT+02:00 Markus Schneider <markus.schneider@xxxxxxxxxx>:
> Hi Sebastien,
>
> is was looking at your code and setting the "binary.location" hard, is
> the one i struggle with.
> A storage.configuration on each field i see the advantage, but i should
> be a default value, that you need not redefine on every field.
>
Yes, I think also having it configurable from the backend is better.
I already plan to had a default configuration so by default user have
nothing to do.
They only change it if they want some customisation.
>
> What i think about instead of choosing it on model/field side, maybe a
> rule system would be more flexible. So that you have the information on
> each ir.attachment where it stored. So one possible rule is:
>
> model=product,field=image => Filestore
>
> then you can have additional rules like filesize>1MB or something like
> this. (asking myself: Hmm should we use OpenERP domain syntax?)
>
Yes having rule can be a posibility. But I prefer to have a real need
before adding this kind of feature because it will be not so easy to
support and also I have no idea of what exactly a customer will really need
(which rule, where we store..). I prefer to have a simple solution for now
and them we can refactor/extend the existing code if a customer have the
need and the budget ;)
By the way your idea is interesting ;)
For now I just want to implement a storage per model/field so we can easily
serve image with nginx (apache or want you want) without using OpenERP. (I
want to have it by model/field in order to share only public data ;) )
> Don't ask me who needs this, just share my mind, what can be possible ;)
>
> Thanks for your feedback. I think I am going to implement the
"storage.configuration" ;)
> Greetings
>
> Markus
>
> On 17.06.2014 08:55, Sebastien Beau wrote:
> > Hi Paul and Markus.
> > I did some update on my code
> >
> https://code.launchpad.net/~akretion-team/server-env-tools/server-env-tools
> >
> > And I start to refactor the product image module based on it
> >
> https://code.launchpad.net/~akretion-team/openerp-product-attributes/openerp-product-attributes-product-image
> >
> > Note, I am thinking about adding an object "storage.configuration" and a
> > field "storing_configuration_id" on the model "ir.model.fields". The
> > idea will to use a default storing configuration for every field (on
> > file sytem for exemple) but after we will be able to customise on every
> > field from the backend where where you want to store each binary/image
> > fields (database, S3, ftp, SFTP, Filestore....)
> > Do you like the idea? (not so hard to implement)
> >
> >
> >
> >
> > 2014-05-14 11:02 GMT+02:00 Paul Catinean <paulcatinean@xxxxxxxxx
> > <mailto:paulcatinean@xxxxxxxxx>>:
> >
> > Hello Sebastien,
> >
> > I was just trying to find a solution for this yet again and I
> > noticed there is no complete module out there for product images
> > that is accessible to everyone (you are right about the default_code)
> >
> > This is an interesting project and I hope to contribute to it if I
> > can, code, testing etc
> >
> > Thanks for you efforts and keep us posted
> >
> >
> > On Wed, May 14, 2014 at 11:44 AM, Markus Schneider
> > <markus.schneider@xxxxxxxxxx <mailto:markus.schneider@xxxxxxxxxx>>
> > wrote:
> >
> > Hi Sebastien,
> >
> > we just looking on your solution to get ideas how to implemented
> a
> > Attachment field with additional meta data. This helps us a lot,
> > thank
> > you for sharing your work.
> >
> > So i just want to share my thoughts about your implementation.
> > So you
> > solve two problems in one module. I suggest to split it.
> >
> > 1) Part: Giving us a new field typ which store more metadata for
> > a file,
> > like Imagesize.
> >
> > 2) Part: Changing the storage behaviour of ir.attachment. So for
> > your
> > case, that you can store the files in a separate path in the
> > file-system. (I think the reason is to provide them directly
> > with other
> > fast web server).
> >
> > As i know there are some other concepts to extend the storage
> > location
> > for ir.attachment like MongoDB or some cloud specific API. So at
> > the end
> > it would be great to combine some metadata binary field with some
> > storage location module total free.
> >
> > Kind Regards
> >
> > Markus
> >
> > On 01.05.2014 11:55, Sebastien Beau wrote:
> > > Hi all,
> > >
> > > If like me you want to store image and binary in you file
> > system instead
> > > of the database this mail can interest you.
> > >
> > > Since version 6 we make some improvement in the product image
> > module in
> > > order to be able to store image in the file system
> > >
> > (
> http://bazaar.launchpad.net/~product-core-editors/openerp-product-attributes/7.0/files/head:/product_images/
> )
> > > But I am not satisfy by the work done (I did it) because this
> > > implementation only support the image of product. More over we
> > use the
> > > product default code in the path for storing the image and
> > this make
> > > mandatory the default code on product which do not fit with
> > every customer.
> > >
> > > After thinking twice, I think the best solution is to
> > introduce new type
> > > of field that will manage the storage for us. Indeed if we
> > implement
> > > this with a field, we can use it everythere (product,
> > category, user,
> > > company....)
> > >
> > > Here is my proposal:
> > > Adding 3 new fields:
> > > - BinaryField
> > > - ImageField
> > > - ImageResizeField
> > >
> > >
> > > An exemple of how using it will be this :
> > >
> > >
> > > _columns = {
> > > 'binary_test': fields.BinaryField('Test Binary'),
> > > 'image_test': fields.ImageField('Test Image'),
> > > 'image_test_resize': fields.ImageResizeField(
> > > related_field='image_test',
> > > string='Test Image small',
> > > height=64,
> > > width=64,
> > > ),
> > > }
> > >
> > > Adding this kind of field will also create this field (on fly):
> > >
> > > - binary_test_info_id
> > > - image_test_info_id
> > > - image_test_resize_info_id
> > >
> > > Why adding this field?
> > > The aim is simple, I want to read the metadata of my image
> > (path, size,
> > > extension...)
> > > For exemple, if you build an external application maybe you
> > want to get
> > > the path of the image.
> > > In this case you just have to do
> > > "product.image_test_info_id.store_fname" and you get the path.
> > > Acceding to the image with you external application using the
> > images
> > > served by nginx (or apache) is really easy.
> > >
> > > I know that "Explicit is better than implicit." but I think It
> > will be a
> > > paint to add this field manually. I don't see any other
> > solution that
> > > make easy (and compatible with the existing API) to access to
> > the image
> > > content or to the image metadata (using the context is not a
> > good idea
> > > because you may access to the content of a field and the
> > information of
> > > an other field at the same time)
> > >
> > >
> > > I start a POC here :
> > >
> >
> https://code.launchpad.net/~akretion-team/server-env-tools/server-env-tools
> > >
> > > How this work
> > >
> > > First the object "binary.binary"
> > > =================================
> > >
> > > It's just a table that store the metadata of my binary field
> > (image,
> > > pdf, video...) and store the path of the binary.
> > >
> > > I try to reuse the function to create/write/delete of the
> > > "ir.attachment" class, because is kind of the same feature.
> > >
> > >
> > > Then the new fields :
> > > ========================
> > >
> > > BinaryField
> > > --------------
> > >
> > > BinaryField is a function field with a "fnct" and a "fnct_inv"
> > already
> > > defined. Basically when I add a pdf in this kind of field, the
> > "fnc_inv"
> > > will create (or update) the "binary.binary" and store the id
> > of the
> > > "binary.binary" in the field "my_field_info_id"
> > >
> > >
> > > ImageField
> > > ---------------
> > > ImageField inherit of BinaryField. The only difference is that
> > > ImageField can have resized Image linked so this class will
> > trigger a
> > > refresh of resized image
> > >
> > >
> > > ImageResizeField
> > > -----------------
> > > ImageResizeField inherit of ImageField. The best way to
> > explain it is to
> > > give an exemple. Let's say that we have added the fields
> > "image_test"
> > > and "image_test_resize" (like on the top of my email)
> > >
> > > First setting a image in "image_test"
> > > -------------------------------------
> > > If you set a image into the field "image_test" then the
> > > "image_test_resize" will be refresh.
> > > The ImageResizefield like the BinaryField create a
> > "xxx_info_id" field.
> > > So in this case the resized image is stored in a
> > "binary.binary" and the
> > > id of this binary is stored in "image_test_resize_info_id"
> > >
> > >
> > > First setting a image in "image_test_resize"
> > > ---------------------------------------------------
> > > Giving the posibility to set the image from the resize field is
> > > necessary (OpenERP already do that on product image).
> > > So if you set an image in this king of field, the image will
> > be store in
> > > the ImageField related, this mean in the "image_test" and then
> > the cache
> > > of the ImageResizeField will be refresh.
> > >
> > >
> > > If you need more details, ask me. I will push some change/fix
> > in the
> > > branch so be carefull when you update the code when you test
> it.
> > > (creating a new db after pulling the code maybe the best idea)
> > >
> > >
> > > If you are ok with that I will propose a new version of
> > product_image
> > > based on it.
> > >
> > > If you have better naming idea, share it !
> > >
> > > Thanks for your feedback.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Dipl.-Comp.-Math. Markus Schneider
> > Softwareentwickler
> >
> > initOS GmbH & Co. KG
> > An der Eisenbahn 1
> > 21224 Rosengarten
> >
> > Mobil: +49 (0)172 2303699 <tel:%2B49%20%280%29172%202303699>
> > Phone: +49 (0)4105 5615613 <tel:%2B49%20%280%294105%205615613>
> > Fax: +49 (0)4105 5615610 <tel:%2B49%20%280%294105%205615610>
> >
> > Email: markus.schneider@xxxxxxxxxx
> > <mailto:markus.schneider@xxxxxxxxxx>
> > Web: http://www.initos.com
> >
> > Geschäftsführung:
> > Dipl. Wirt.-Inf. Frederik Kramer & Dipl.-Ing. (FH) Torsten
> Francke
> > Haftende Gesellschafterin: initOS Verwaltungs GmbH
> >
> > Sitz der Gesellschaft: Rosengarten – Klecken
> > Amtsgericht Tostedt, HRA 201840
> > USt-IdNr: DE 275698169
> > Steuer-Nr: 15/205/21402
> >
> > --
> > Mailing list: https://launchpad.net/~openerp-connector-community
> > Post to : openerp-connector-community@xxxxxxxxxxxxxxxxxxx
> > <mailto:openerp-connector-community@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~openerp-connector-community
> > More help : https://help.launchpad.net/ListHelp
> >
> >
> >
>
> --
> Dipl.-Comp.-Math. Markus Schneider
> Softwareentwickler
>
> initOS GmbH & Co. KG
> An der Eisenbahn 1
> 21224 Rosengarten
>
> Mobil: +49 (0)172 2303699
> Phone: +49 (0)4105 5615613
> Fax: +49 (0)4105 5615610
>
> Email: markus.schneider@xxxxxxxxxx
> Web: http://www.initos.com
>
> Geschäftsführung:
> Dipl. Wirt.-Inf. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
> Haftende Gesellschafterin: initOS Verwaltungs GmbH
>
> Sitz der Gesellschaft: Rosengarten – Klecken
> Amtsgericht Tostedt, HRA 201840
> USt-IdNr: DE 275698169
> Steuer-Nr: 15/205/21402
>
References
