Hi Kirk, Thanks for your comments. By the way, I enjoyed your cameo appearance in Intissar’s session on 4D Summit 2020. I agree with ‘getting with it on ORDA’ and leaving the past behind! I regret that I have to resort to ‘classic’ in triggers still; I was hoping 4D would provide a “This.” syntax for programming in a trigger, but I suppose they have so much on the go and a horse can only run so fast! Anyway, I comment on your comments with ——— in the front. Thanks for your input! — Chris
> On Apr 24, 2020, at 8:37 AM, Kirk Brooks via 4D_Tech <[email protected]> > wrote: > > Hi Chris, > > On Fri, Apr 24, 2020 at 1:54 AM Chris Belanger via 4D_Tech < > [email protected]> wrote: > >> • Loading a system document into a BLOB, then using BASE64 ENCODE to store >> it in a TEXT field; —— This is because I am using ORDA exclusively, and as you know, ORDA does not support BLOBs. So I need to convert the BLOB into a TEXT, store it a field, save it, and then the trigger needs to convert it back to a BLOB and save it as a file on disk. It doesn’t need to be particularly fast in this application; They drag the file onto the dropzone and the action takes place. There is no ‘batching’ of this methodology. Once the file is created on the Server computer, then the TEXT [aka BLOB] is cleared out and no longer takes any storage. (Actually, it never really does…) —— > > Out of curiosity why not simply blob the document into a blob field? Even > if it's a temporary record just for this purpose. The advantage is the > blobing action takes place on the client and when the record is saved the > data actually moves to the server. Then the operation of saving the blob to > disk can be put into a different method and executed on the server. I found > this gave better reliability (this was happening with 4D connected over the > internet) because I could check where the data actually was at each step > along the way and better resiliency because I could continue a long > operation if it was interrupted. > > • the TRIGGER method (running on 4D server) unpacks it and creates / >> updates the files in its ‘Library’ directory on disk. >> > Following from above doing that much heavy processing in a trigger seemed > fragile. > > >> Now I need to be able to retrieve the contents of these files for 4D >> [Client]. >> I can display the files in a Web Area > > ** But I am looking for a simple way to get 4D Server to ’send’ the data to >> the CLIENT (4D) upon request. >> > So do you want to initiate the transfer from the web page or from the > Client? > From the Client it's pretty straightforward : > > Select the doc and fire some method that executes on the server > > This server-side method gets the document and a blob and returns it to the > Client as $0 > > Back on the client you manage saving it to the selected location on disk —— So I think you are saying that ‘execute on server’ will perform this mission? I see. I thought it only returned the process number to the client. I don’t see how it returns anything in $0 that would be useful for this situation. But I would be happy to be proven wrong on that one. —— > > > Depending on the size and number of the documents I would think about using > temp records: blob into the record on the server and return a list of said > records to the client. The client gets them, writes the blob to disk and > deletes them. Better ability to resume/continue of dropped connections are > an issue. > > Do I have to use Workers, or Stored Procedures, or something? >> > Maybe. If lots of users are doing this a lot of the time it might be > beneficial. But that's more of a tactical question. Whatever code they > would be running is going to involve the decisions you make on the above > tasks. I have used stored methods for this sort of thing (workers didn't > exist yet). The stored methods work well when you put the documents in > records. —— I also used stored procedures in the past. It required some acrobatic coding; I would pause / start it, etc. I was hoping there was a more straightforward possibility that I just don’t know about yet — you-know, in the ’spirit of ORDA’! —— > > -- > Kirk Brooks > San Francisco, CA > ====================== > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
