Hello people, thanks for all of the suggestions and feedback. Several of
you pointed out that my thinking was in the fuzzy-to-nonsense range. I hate
you all. So much. Not really, the comments were completely on the mark. I'm
trying to find a decent default option that will work over a wide range
Hi all,
I am really getting into ORDA-style programming with v17 and loving it.
Here are my questions:
1) do table forms have any relevance in ORDA anymore? I don’t want to mix
‘classic’ 4D in new projects, and so it seems that I should use project forms
exclusively. What’s your take on that?
if you must serve directly from 4D, conceptually,
the On Web Connection database method must process the "range" HTTP header,
https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
and return the requested video segment.
you could either splice the BLOB stored in your database
on the client side, technically it could be as easy as having an HTML5 video
tag and specify an mp4 file as its src attribute,
but for performance you can't just serve a large video file directly from the
web folder as if it were a still jpeg photo.
you would need a purpose build video
In years gone by, I used to provide this feature through an Escape plugin.
It seems to me that one should be able to do this through a WebArea. I am
obviously getting thick, but when I read the Web Area Language Reference I seem
to be missing a lot.
I thought it would be something simple like
Following up on Jim’s and other responses I would venture to say that one good
solution memory and performance wise would be:
- loop thru records using NEXT RECORD, or GOTO SELECTED RECORD
- preallocate a BLOB to build your text/json; say 5MB is your limit, or maybe
50Mb, or 500Mb, you pick your
On Sep 15, 2018, at 12:07 AM, David Adams via 4D_Tech <4d_tech@lists.4d.com>
wrote:
>
> Short version:
> I need to load some fields from records into a big text thingy.
>
> The code runs on the server-side only.
>
> I'm keen to preserve RAM.
[snip]
> TL;DR version
> I'm working in V17 and
Hey David,
You know, you say that RAM is the primary limiting factor but then also say
you're only interested in actual timing tests. Umm. Seems like the coding
version of the the building contractor talking to a client:
You can have it fast
You can have it cheap
You can have it done well
Pick
With a little up front work, you can create a nice wrapper for SELECTION TO
ARRAY/SELECTION RANGE TO ARRAY where you just pass an array of field pointers.
You can use a process 2D array of each type to dynamically allocate/deallocate
the necessary arrays and just manipulate the pointers. Some
Thanks Keith, that all sounds pretty right to me too. And, yes, I'm
chunking the pushes into batches to avoid a truly massive text object, when
necessary. I don't know about with SQL Server and don't remember about
MySQL, but with Postgres it's important to avoid single row inserts where
possible.
Hi
GOTO SELECTED RECORD (or any ORDA equivalent of navigating record by record)
will be slower than S2A but will take less RAM. That's based on actual
experience.
Building up a single big text thingy will have RAM (and eventually potentially
performance) issues if using straight string/text
Short version:
I need to load some fields from records into a big text thingy.
The code runs on the server-side only.
I'm keen to preserve RAM.
What are the trade-offs in V17 between *GOTO SELECTED* record and *SELECTION
TO ARRAY*? I've been using *SELECTION TO ARRAY*, but it's hard to read,
12 matches
Mail list logo
