> I think it was unfortunate that "some thing like a hash table" was
mentioned,
> in passing, when the object feature was explained in detail.
Thanks *very* much for the clarification.
Of course now, we don't even know that about object field indexes ;-)
> it was simply a demo to show how using
Keisuke,
You are *the* man on character encoding stuff in 4D, so thanks for adding
your observations.
I'm likely to be working with nothing but low ASCII, Latin1 data, for what
it's worth. Just simple names for keys and numbers for most values.
As far as the planning quesiton goes, I'm just tryi
one more thing,
it is not incorrect to do something like
{
"\u0066\u006F\u006F":"\u0062\u0063\u0072"
}
instead of {"foo":"bar"}
it's an extreme example,
but it happens all the time in non-ASCII JSON.
I may prefer one over the other,
but really I don't care, and nor should I care,
because it wo
Hello,
I think it would not be telling the full story if you just focus on how UTF-16
takes double the size for standard ASCII, and therefore uneconomic.
and I am not speaking because UTF-16 actually takes less space than UTF-8 for
Japanese text.
one must take into account that standard Windows
On Wed, Jul 12, 2017 at 6:41 AM, Lee Hinde via 4D_Tech <4d_tech@lists.4d.com
> wrote:
> On Tue, Jul 11, 2017 at 3:10 AM, David Adams via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
> > * Use a header object that describes the 'columns' and then use compact
> > JSON arrays for the data. Rob Laveaux
Okay, I'm back and think that I get it now. And, yeah, storage space with
4D object fields is definitely a planning issue. Headline result: Copy and
paste a 1MB JSON from a text editor and save it in 4D and it's likely to
take about 2MB to store. More below. Corrections welcomed. I've also posted
m
not really following this thread but...
if compacted-ness is primary.
JSON, TSV, whatever text format
save to disk
zip (using 7zip or whatever) via LEP
document to blob
access to the data is not easy, you may need to create a searchable set
of keywords (or something)
but that would give most co
On Tue, Jul 11, 2017 at 3:10 AM, David Adams via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> * Use a header object that describes the 'columns' and then use compact
> JSON arrays for the data. Rob Laveaux reminded me about this option some
> months back and it's a really decent compromise.
>
That se
I was making some related comments on the forums in France today and
Rob Laveaux, a hero of the 4D world, made a great technical post:
Hi David,
Please elaborate what makes you conclude this?
You seem to imply that objects fields are stored in JSON format, but I'm
sorry ... that is not true. Tak
I've not delved into 4D's object fields much yet and now have a situation
where they make sense...but may not be workable. I'm looking for some
comments, advice and, hopefully, code.
I have been under the misimpression that object fields use an efficient
binary format for storage. Based on my own
10 matches
Mail list logo