photo manipulation in Studio 6.1 and/or Postgres

Mike Matthews omnis at lineal.co.uk
Tue Feb 14 17:55:28 EST 2017


Hello Doug & Clifford, 

The backups don't necessarily get big, well they do possibly.  We store our images in a 2nd DB, with all of the main data in a primary DB.  This primary DB is smaller and is easier to export and send to us for help, etc.

But we support a file path and a DB storage regime.  It all depends on how you want it to work, backup, etc.

Just another view.

Mike

Sent from my iPad

> On 14 Feb 2017, at 21:24, Doug Easterbrook <doug at artsman.com> wrote:
> 
> hi clifford:
> 
> its always nice to occasionally have a contrarian opinion to the great Clifford Ilkay - because it doesn’t happen often :)
> 
> I understand why some people don’t store images in a database.    Perfectly fine if you control the resources.
> 
> On the other hand, we store images in our postgres database so we can use pg_dump for a snapshot with *logical data integrity* and send it to us, or to a customer offsite backup or what have you.   This gives transportability of data as well - without fuss
> 
> we can scale the image on the way out of the database, just as easily as scaling it on the way out of a file, so thats a wash, time wise.
> 
> 
> so the key benefit of images being in a database (for us) are
> — single command to snaphot the database with logical integrity
> — single data access point (pgdam), so we don’t need file shares or anything set up to point to servers, that could be on any machine.
> — no fuss about what the user might do with images stored elsewhere and possibly lose them.
> 
> 
> 
> this is a preference, so I thought I’d highlight some reasons to put it in the database.
> 
> 
> the contrarian side is that database backups get big quickly.
> 
> 
> 
> 
> 
> 
> 
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
> 
> 
> 
> 
> National User Conference, May 8-11, 2017
> https://tickets.proctors.org/TheatreManager/95/online&perf=27956
> 
>> On Feb 14, 2017, at 12:04 PM, CLIFFORD ILKAY <clifford_ilkay at DINAMIS.COM> wrote:
>> 
>> On 14/02/17 09:27 AM, Jim Pistrang wrote:
>>> Hi all,
>>> 
>>> I'm storing some photos as binary data in a Postgres database.  The column is defined as a PICTURE in the Omnis schema, and the user inserts/updates by pasting a photo into a picture field (kPictureObject) in an Omnis window.  I can check the size of the pasted picture with the binlength() function and not do an insert or update if the image is too large.
>>> 
>>> My immediate problem:  I haven't been checking the size up till now, and there are about 500 photos already in the database that are really big (8mb or so).  Is there a way in Omnis (or with some other tool) that I can fetch an image, reduce its size, and then update postgres?
>>> 
>>> Thanks from snowy New England,
>>> 
>>> Jim
>> 
>> Hi Jim,
>> 
>> I think you use OS X. If so, "batch resize image" yielded this: <http://osxdaily.com/2013/01/16/batch-image-conversion-mac-os-x-preview/>. I haven't used it. I have used ImageMagick and Photoshop to batch resize and both worked well.
>> 
>> You're underscoring why I never store images in the database. I store a relative file path and set the base path as a config option. I store the highest resolution and then transform the images on the fly, as necessary. It's rare that I'll need just one size of an image.
>> 
>> --
>> Regards,
>> 
>> Clifford Ilkay
>> 
>> + 1 647-778-8696
>> 
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com






More information about the omnisdev-en mailing list