O$ PostgreSQL large objects and OSX

[Doug Easterbrook]

I beg to differ.

I’d still rather keep it in the database and do it in the background as a worker job.

 If an end user starts something before they go home, the act of quitting an application, the act of uploading and the act of going home are independent threads, so to speak.

the solution is not a progress bar.

the solution is a message that says.  You have logged off, the application will quit when the upload is finished…. an then you check the worker thread’s completion before actually quitting omnis.

making them see a progress bar before they are allowed to go home is quite 'bad form', as they say in england.     In most of the world, they’ll go home anyway.    Independent events.

still not convinced doing a separate file transfer and synchronizing the saving of some oid or pointer and all the hassle of doing **different** things to toy with the SQL database has any benefit.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 536-1205    Fax (403) 536-1210

> On Jun 24, 2015, at 4:17 PM, Bastiaan Olij <bastiaan at basenlily.me> wrote:
> 
> Hi Doug,
> 
> I beg to differ. Background threads prevent the interface from becoming
> not-responding or blank, but if you've uploading for 10 minutes, it
> still just sits there doing whatever it needs to do in the background
> for 10 minutes with no feedback whatsoever to the user (other then, I'm
> still doing something in the background). Very annoying if the user
> wants to go home because he/she just decided to upload the days work to
> the server. You may still want to chunk the upload into smaller pieces
> so you can show how far along the process is and give the user an ETA
> before he/she can safely close off the application and go home.
> 
> Cheers,
> 
> Bas
> 
> On 24/06/2015 9:41 pm, Doug Easterbrook wrote:
>> I imagine this may be an interesting thread…  there are some pro’s/cons’s..   so if its ok with all, can we continue with a little chatting….
>> 
>> Bas’s comment below about uploading/downloading large blobs hanging the interface —  that is long solved with the background threads.    We have maps of venues (that can be large) and copies of our Theatre.lbr (compressed = 20 megs) that we upload and download on background threads using the dam and standard SQL calls.   User doesn’t see the delay.
>> 
>> Using file i/o ‘on the side’ has no benefit because that is blocking in studio 5.2.3
> 
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com