Data Persistence

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
J. Landman Gay wrote:
 > On 7/27/18 2:26 PM, Richard Gaskin via use-livecode wrote:
 >> if the result is empty then
 >>    return "Error in getTempSavedParams: "& the result for error
 >> end if
 >
 > I believe you had a thinko: "not empty", yes?

Indeed I did - thanks.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Bob Sneidar wrote:

 > I tried reading an "LSON" format, but it's not straight forward. It's
 > easier to simply arrayDecode the LSON and work with the array.

I think there's a misunderstanding here:  LSON *is* the standard LC
encoded array.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 07/27/2018 02:58 PM, Mike Bonner via use-livecode wrote:
> Your Braiiiinssss. will be assimilated. (borg zombies FTW)

Yes. More brains please.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Mike Bonner wrote:

 > On the subject of sqLite/memory databases and preferences/data
 > persistence, rather than using an array, and doing the encode/decode
 > stuff, would it make sense to do the following..
 > 1. open an empty in memory database
 > 2. attach a disk based database
 > 3. copy the required table(s) from disk base to memory base
 >
 > At this point, for data reads you have a super fast sqlite in memory
 > database.  For updates, do a double update, both in memory, and disk.

Whether using LC-native LSON or going through the externals interface to
manage the SQLite RDBMS, getting any data from disk always has
tradeoffs, sometimes favoring one method over another.

ArrayEncode is a single function call, so it's not like it's onerous to use.

SQLite's b-tree is a good one, so while the steps needed internally to
traverse it are vastly more complex than the steps needed to traverse an
array's hash, both are handled in machine-compiled C so it's not a big
deal either way.

This reiterates the point I'd made earlier:
 > It seems like this would be more efficient than re-encoding an array
 > every time there is an update and writing the whole thing out to disk
 > each time, rather than updating just whatever small change might need
 > to be made to sqlite.

This is the upside of an RDBMS's complex b-tree: disk paging.  As I'd
written earlier, if the data size is large enough that LC's machine-code
serialization is slower than SQLite's SQL parsing + machine-code b-tree
traversal, then SQLite would be the winner in that instance where raw
performance may offset the additional requirement mixing SQL scripting
with LC Script, and of no longer having a completely self-contained EXE
(only Mac embeds externals and drivers within the bundle; Win and Linux
at that point require use of an installer to install the multiple parts
where the standalone can find them and the user won't mess with them).

You'd be surprised how fast LC is for many things, though. I've written
routines using flat files that were able to do simple queries in LC
Script about 20% faster than SQLite.

But even there, it's about project requirement.  If you need richer
querying relying on relationality, nothing scripted in LC will come
close in raw performance to the well-honed relational engine in SQLite.

But also, remember that the file system itself is a b-tree-based storage
system, well optimized for general use, automatically ACID (in journaled
file systems), and super easy to use.  Clustering as with Canela's
LiveCloud DB, or even as separate file per document/record, can be quite
efficient for some needs.

SQLite is a wonderful toolkit.  But with so many ways to store,
retrieve, and work with data, we can pick and choose for the task at hand.

At a certain point, discussions about "SQL vs <your favorite non-SQL
solution here>" are too similar to those of the NoSQL world last decade
when those started taking off.  None of the many passionate arguments
have managed to rid the world of MongoDB, CouchDB, Neo4J, or any other
non-SQL storage system, nor have they displaced the valuable role of a
good RDBMS where relationality is needed.  We have more options today
than ever before, so we can pick whatever gets the job done.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Wait, you can attach a disk based database to a memory database??

Bob S


> On Jul 27, 2018, at 15:19 , Mike Bonner via use-livecode <[hidden email]> wrote:
>
> On the subject of sqLite/memory databases and preferences/data persistence,
> rather than using an array, and doing the encode/decode stuff, would it
> make sense to do the following..
> 1. open an empty in memory database
> 2. attach a disk based database
> 3. copy the required table(s) from disk base to memory base


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
I know. I actually saved an arrayEncoded livecode array to file, then see if I could parse it for the purposes of creating a searchable array handler. I had to give up because as I sair, the format is not straightforward.

Bob S


> On Jul 27, 2018, at 15:47 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Bob Sneidar wrote:
>
> > I tried reading an "LSON" format, but it's not straight forward. It's
> > easier to simply arrayDecode the LSON and work with the array.
>
> I think there's a misunderstanding here:  LSON *is* the standard LC encoded array.
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Yes
<Wait, you can attach a disk based database to a memory database??

On Mon, Jul 30, 2018 at 8:45 AM Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Wait, you can attach a disk based database to a memory database??
>
> Bob S
>
>
> > On Jul 27, 2018, at 15:19 , Mike Bonner via use-livecode <
> [hidden email]> wrote:
> >
> > On the subject of sqLite/memory databases and preferences/data
> persistence,
> > rather than using an array, and doing the encode/decode stuff, would it
> > make sense to do the following..
> > 1. open an empty in memory database
> > 2. attach a disk based database
> > 3. copy the required table(s) from disk base to memory base
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
Sorry.. To elaborate, yes you can attach a disk based db to a memory db.
Then you use dot notation to specify which database you're working on.

So it would be a regular attach-- attach pathtodatabase.db as dbname
Then any place you would specify a table name it would be dbname.tablename



On Mon, Jul 30, 2018 at 8:51 AM Mike Bonner <[hidden email]> wrote:

> Yes
> <Wait, you can attach a disk based database to a memory database??
>
> On Mon, Jul 30, 2018 at 8:45 AM Bob Sneidar via use-livecode <
> [hidden email]> wrote:
>
>> Wait, you can attach a disk based database to a memory database??
>>
>> Bob S
>>
>>
>> > On Jul 27, 2018, at 15:19 , Mike Bonner via use-livecode <
>> [hidden email]> wrote:
>> >
>> > On the subject of sqLite/memory databases and preferences/data
>> persistence,
>> > rather than using an array, and doing the encode/decode stuff, would it
>> > make sense to do the following..
>> > 1. open an empty in memory database
>> > 2. attach a disk based database
>> > 3. copy the required table(s) from disk base to memory base
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as dbname

On Mon, Jul 30, 2018 at 8:55 AM Mike Bonner <[hidden email]> wrote:

> Sorry.. To elaborate, yes you can attach a disk based db to a memory db.
> Then you use dot notation to specify which database you're working on.
>
> So it would be a regular attach-- attach pathtodatabase.db as dbname
> Then any place you would specify a table name it would be dbname.tablename
>
>
>
> On Mon, Jul 30, 2018 at 8:51 AM Mike Bonner <[hidden email]> wrote:
>
>> Yes
>> <Wait, you can attach a disk based database to a memory database??
>>
>> On Mon, Jul 30, 2018 at 8:45 AM Bob Sneidar via use-livecode <
>> [hidden email]> wrote:
>>
>>> Wait, you can attach a disk based database to a memory database??
>>>
>>> Bob S
>>>
>>>
>>> > On Jul 27, 2018, at 15:19 , Mike Bonner via use-livecode <
>>> [hidden email]> wrote:
>>> >
>>> > On the subject of sqLite/memory databases and preferences/data
>>> persistence,
>>> > rather than using an array, and doing the encode/decode stuff, would it
>>> > make sense to do the following..
>>> > 1. open an empty in memory database
>>> > 2. attach a disk based database
>>> > 3. copy the required table(s) from disk base to memory base
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
Interesting... does it load the file database into memory?

Bob S


> On Jul 30, 2018, at 08:19 , Mike Bonner via use-livecode <[hidden email]> wrote:
>
> Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as dbname


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
No, the memory db is in memory, the file db is still a file.  Also forgot,
you should probably quote the filename 'pathtofile.db' otherwise it gets
confused (unless you use a file with no extension.

The nice thing about this is you can have your nice persistent file db,
open a memory db, then do a create table main.tablename as select * from
attachedtable.tablename at which point you have the speed benefits of using
an in memory database.  Just gotta keep both updated if you make changes
that need to be persistent, but thats no different than loading an array,
and having to keep the disk based encoded array up to date with changes.
Faster if anything since you don't have to write the whole thing every time.

On Mon, Jul 30, 2018 at 3:46 PM Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Interesting... does it load the file database into memory?
>
> Bob S
>
>
> > On Jul 30, 2018, at 08:19 , Mike Bonner via use-livecode <
> [hidden email]> wrote:
> >
> > Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as
> dbname
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
That's an interesting strategy. I'm gonna mull over this and see if I can find an application for it. The first thing that comes to my mind is that when I am in the field, I sometimes cannot connect to my database, because the customer network is heavily firewalled, and my cell phone can't get a good connection to be used as a hotspot.

I have thought about adding a "Work Offline" option, and taking all the data I currently have queried, and migrating it to memory databases, then synching up later might be an option. I'd have to lock writes somehow on the offline records in the parent DB, so I don't have to deal with conflicts, and I'd have to prevent certain operations while offline, but it's doable.

Bob S


> On Jul 30, 2018, at 15:14 , Mike Bonner via use-livecode <[hidden email]> wrote:
>
> No, the memory db is in memory, the file db is still a file.  Also forgot,
> you should probably quote the filename 'pathtofile.db' otherwise it gets
> confused (unless you use a file with no extension.
>
> The nice thing about this is you can have your nice persistent file db,
> open a memory db, then do a create table main.tablename as select * from
> attachedtable.tablename at which point you have the speed benefits of using
> an in memory database.  Just gotta keep both updated if you make changes
> that need to be persistent, but thats no different than loading an array,
> and having to keep the disk based encoded array up to date with changes.
> Faster if anything since you don't have to write the whole thing every time.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
And don’t forget about the way mobile can dump everything at any time too. So you would end up with mobile disk and memory as the cache for the upstream DB server.
On Jul 31, 2018, 11:23 AM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> That's an interesting strategy. I'm gonna mull over this and see if I can find an application for it. The first thing that comes to my mind is that when I am in the field, I sometimes cannot connect to my database, because the customer network is heavily firewalled, and my cell phone can't get a good connection to be used as a hotspot.
>
> I have thought about adding a "Work Offline" option, and taking all the data I currently have queried, and migrating it to memory databases, then synching up later might be an option. I'd have to lock writes somehow on the offline records in the parent DB, so I don't have to deal with conflicts, and I'd have to prevent certain operations while offline, but it's doable.
>
> Bob S
>
>
> > On Jul 30, 2018, at 15:14 , Mike Bonner via use-livecode <[hidden email]> wrote:
> >
> > No, the memory db is in memory, the file db is still a file. Also forgot,
> > you should probably quote the filename 'pathtofile.db' otherwise it gets
> > confused (unless you use a file with no extension.
> >
> > The nice thing about this is you can have your nice persistent file db,
> > open a memory db, then do a create table main.tablename as select * from
> > attachedtable.tablename at which point you have the speed benefits of using
> > an in memory database. Just gotta keep both updated if you make changes
> > that need to be persistent, but thats no different than loading an array,
> > and having to keep the disk based encoded array up to date with changes.
> > Faster if anything since you don't have to write the whole thing every time.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Hi John, welcome to the gang.

FWIW, if your needs are super-simple, saving the values of various fields -
and especially if those fields are not going to have multi-line values, you
may want to check out the keywords 'combine' and 'split'.

Combine takes a (simple, not nested) array and combines it into flat text with
the delimiters you specify for keys and records; split does the reverse.

So what I've done for this kind of case - simple mobile app, storing some
simple values in case it gets backgrounded - is keep all the data in an array;
update the array when the data changes (e.g. user edits a field, or some other
event) - and then calling a command along these lines:

        command storeSettings
           global gaSettings
           local tPath, tFlat
           put gaSettings into tFlat
           combine tFlat using return and tab
           put format("file://%s/settings.txt", prefsFolder()) into tPath
           put tFlat into URL tPath
        end storeSettings

The advantage over arrayEncode is that the file is very readable - with the
above delimiters, each line is an entry from the array, in the format
<key><tab><value>.  I know Richard questions why one would ever want to read
"LSON": my answer is that during development it can be helpful, either
directly when developing on desktop, or attaching to error reports once the
app has moved onto a device.

The disadvantage is that you need a couple of characters that you know won't
be included in either key or value. It doesn't have to be tab and return; you
could use "◊" and "¶" - but if you have any doubts of what your users might
ever need to enter, this is an issue.

HTH,

Ben


On 27/07/2018 19:37, John McKenzie via use-livecode wrote:

>
>   Thanks for the extra comments everyone. Glad my thought process was
> correct, databse is overkill, saving every text change is too much,
> etc, etc.
>
>   As I said I will not be able to really do anything until next week.
>
>   Thanks for mentioning the closeField command guys. I will check it
> out, but the name sounds like it explains it, loose focus on the field,
> field is closed, handling activated.
>
>   Because I like word play I might make my own text file format, the
> "Extended Livecode Optimized Serialized Object Notation" format or
> ELSON. It adds just enough features to LSON to make identical to JSON.
> Being stupid and redundant it will be the hot new buzzword in the
> computing industry.
>
>
>   Using arrays intigues me, especially if I can just keep it in RAM (It
> is a small amount of data for sure).
>
>   Thanks for your continued help everyone. Off to super busy weekend
> planning and working on an event for Sunday. Will update you/ask
> follow-ups next week.
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
Ben Rubinstein wrote:

 > FWIW, if your needs are super-simple, saving the values of various
 > fields -  and especially if those fields are not going to have
 > multi-line values, you may want to check out the keywords 'combine'
 > and 'split'.
 > The advantage over arrayEncode is that the file is very readable -
 > with the above delimiters, each line is an entry from the array, in
 > the format <key><tab><value>.

An excellent option for single-line name-value pairs.


 > I know Richard questions why one would
 > ever want to read "LSON": my answer is that during development it can
 > be helpful, either directly when developing on desktop, or attaching
 > to error reports once the app has moved onto a device.

To clarify, my only one-size-fits-all rule on this is that there is no
one-size-fits-all-rule for any of this. :)

What's best for a given circumstance depends on the given circumstance.

I use a format I call ISHI for my CMS and a growing range of other
things.  I'll get around to documenting it later, but it's little more
than a slightly-augmented use of split and combine.  As such, it gives
me blinding speed in CGI environments where every millisecond matters,
while retaining the flexible ease of plain text that can be written
anywhere in anything, a valuable trait for a system based around textual
content authoring.


Uses cases where LSON (LC's binary output from arrayEncode) is favorable
have different requirements, such as array depth.  I use LSON in systems
where I need the flexibility of a schema-free format and the ability to
employ any level of depth to keep document internals separate from one
another for instant parsing.

Humans are very good at handling one- and two-dimensional writing; e.g.,
strings and tables.  Easy to conceptualize, easy to maintain.

Once you add a third dimension things get murky, increasing cognitive
load for writing and machine load for parsing.

With 3 or more dimensions, it's often more productive to craft a UI to
edit the data, something that's super-easy to do in a tool like LiveCode.

And once you've made a UI for that, the storage format no longer
matters, so there's no downside to keeping it in LC's native binary LSON
format.

There are probably dozens of other use cases favoring different formats;
these are just a couple examples.  None are hard to work with, so we can
pick and choose each according to the needs of the task at hand.

With LC v9.0.1 being able to examine raw array data during development
has never been easier, thanks to the recently-fixed tree widget: drop
one on a card, toss an array into it, see and edit everything easily.



 > The disadvantage is that you need a couple of characters that you know
 > won't be included in either key or value. It doesn't have to be tab
 > and return; you could use "◊" and "¶" - but if you have any doubts of
 > what your users might ever need to enter, this is an issue.

Aye, and there's the rub: now you've created another format standard. :)

https://xkcd.com/927/

Split and combine work naturally on tabular data where either the first
column is a key or a sequential integer series can be good keys.

And as long as the data associated with each key is single line it'll
work wonderfully.

But once element data includes returns, it becomes three dimensional.
Not too onerous, reasonably efficient, provided you keep in mind a few
things of the sort you mentioned here, about making sure your delimiters
will never occur in the data itself, lest you need to escape those
delimiters, which may at times require a means to escape the escapes.

I spent some much time poking fun at the most common form of that a
while back, Comma-Separated Values, here:
http://www.fourthworld.com/embassy/articles/csv-must-die.html

It's a generally dismissible article unless you enjoy the comically
strident tone, but the note toward the end may be helpful for choosing
delimiters at least matching those in fairly common use.


The challenge with any plain-text expression of multidimensional data
becomes more evident the moment you need more depth beyond three.

And that's why serialization formats were created.

XML led the pack for a long time, offering not only richly hierarchical
data expression in a universal standard, but with nice extras like
element attributes.

But the closing and ending tag pairs are cumbersome to write and add
bulk to every element and sub-element.

So some clever soul decided to come up with a more compact serialization
that just happened to be parseable using the existing JavaScript engine
(arguably the most common use case since browsers are where API data is
most often consumed), and thus JSON was born.

Along the way, MongoDB came up with BSON (Binary JSON) as a means of
enjoying much of the schema-free flexibility of JSON, but in a binary
format that was both more compact and much quicker for machines to
parse, an excellent choice for large-scale storage in a system like
Mongo (and in some ways the closest match to LC's LSON).

For all of JSON's JS-friendly compactness over XML, hand-writing it can
be tedious and error-prone, so YAML was invented as the answer for those
cases where human-writability is a stronger need than parsing efficiency
(all the rules about white space make it luxuriously readable to humans
at a minor cost to machines to wade through all that).  YAML is most
often use for configuration where settings may lend themselves to data
that might need hierachically-ordered sets deeper than a two-dimentional
table.

Lots of choices, litte dogma.  Just use whatever works well for what you
need to do in the moment.

And if you factor data storage through accessors, you can completely
change the underlying storage format at any time without affecting
anything else in your code base. Pass in arrays, expect arrays back, and
what happens in between becomes a black box whose storage details don't
matter. Go wild, try them all. :)

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
On 31/07/2018 20:03, Richard Gaskin via use-livecode wrote:
> For all of JSON's JS-friendly compactness over XML, hand-writing it
> can be tedious and error-prone, so YAML was invented as the answer for
> those cases where human-writability is a stronger need than parsing
> efficiency (all the rules about white space make it luxuriously
> readable to humans at a minor cost to machines to wade through all
> that).  YAML is most often use for configuration where settings may
> lend themselves to data that might need hierachically-ordered sets
> deeper than a two-dimentional table.
Does anyone have a library to do  array <---> YAML ?

I couldn't find one with Google "livecode YAML" (and various similar
searches :-)

Thanks
Alex.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
Here is one direction...

yamlFileToArray
https://github.com/trevordevore/levure/blob/master/framework/levure.livecodescript

Thanks,
Brian
On Jul 31, 2018, 3:03 PM -0500, Alex Tweedly via use-livecode <[hidden email]>, wrote:

> On 31/07/2018 20:03, Richard Gaskin via use-livecode wrote:
> > For all of JSON's JS-friendly compactness over XML, hand-writing it
> > can be tedious and error-prone, so YAML was invented as the answer for
> > those cases where human-writability is a stronger need than parsing
> > efficiency (all the rules about white space make it luxuriously
> > readable to humans at a minor cost to machines to wade through all
> > that).  YAML is most often use for configuration where settings may
> > lend themselves to data that might need hierachically-ordered sets
> > deeper than a two-dimentional table.
> Does anyone have a library to do  array <---> YAML ?
>
> I couldn't find one with Google "livecode YAML" (and various similar
> searches :-)
>
> Thanks
> Alex.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode

 A little less busy now so I can look at my app some more. As you mat
recall I was asking about data persistence.

 Thank you to the additional people who welcomed me. I contrast this
with the time I asked a question on Usenet about a scripting language I
was learning and the first reply told me I was awful (true, which is
why I was asking questions) and to come back and only ask questions
when I have the script I posted working.

 As for contributing brains. Yeah... I supposed I could fake
that part for awhile. Just do not ask for kidneys as you will get
nowhere there.

 Klaus thank you for mentioning closefield. Did not notice it before
and it seems like it would be just the thing for me. The data is
simple, so I think I will start out by trying to save it all in an
array and doing so every time there is an entry or change to an entry
using closefield.

 And that brings me to today's follow up question. In some cases I have
a button that when pressed put the time inside the neighbouring text
field. So when a plane lands I pressed the button labelled "ATA" and it
puts the current time into a text field next to the ATA button. How
would that count as focus?

 Would having the app place something into the field put focus on the
field?

 What I am really wondering is when it comes to the buttons can I leave
them be because the text fields have code to save their info when the
focus leaves or should I add code to the buttons to tell them after
placing the info into the text field, save same info to an array?

 Thanks.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
Putting text into a field pro-grammatically doesn't fire the openfield and
closefield handlers so yes, you'd need to add code to your button.  You can
either write the code directly, or you can use send (or dispatch) and have
the field do it.. IE send "closefield" to field "whateverfield"...   But if
it were me, I'd just add the code to the button itself.

Actually, I'd probably have the code once, in the card or stack script that
accepts parameters like the long id of the field, data to be saved and
whatever else so that you have a single handler that will work for all of
your saves.

Something like

on saveIt pLongId,pText
    -- code to save pText and associate it with control pLongId
end saveIt

Then you can do..
on closefield
     saveit (the long id of me),(the text of me)
end closefield

Or in a button..
on mouseup
put "Whatever text" into field "myField"
saveit (the long id of field "myField"),the text of field "myField"
end mouseup

Just some thoughts.





On Sat, Aug 4, 2018 at 1:28 PM John McKenzie via use-livecode <
[hidden email]> wrote:

>
>  A little less busy now so I can look at my app some more. As you mat
> recall I was asking about data persistence.
>
>  Thank you to the additional people who welcomed me. I contrast this
> with the time I asked a question on Usenet about a scripting language I
> was learning and the first reply told me I was awful (true, which is
> why I was asking questions) and to come back and only ask questions
> when I have the script I posted working.
>
>  As for contributing brains. Yeah... I supposed I could fake
> that part for awhile. Just do not ask for kidneys as you will get
> nowhere there.
>
>  Klaus thank you for mentioning closefield. Did not notice it before
> and it seems like it would be just the thing for me. The data is
> simple, so I think I will start out by trying to save it all in an
> array and doing so every time there is an entry or change to an entry
> using closefield.
>
>  And that brings me to today's follow up question. In some cases I have
> a button that when pressed put the time inside the neighbouring text
> field. So when a plane lands I pressed the button labelled "ATA" and it
> puts the current time into a text field next to the ATA button. How
> would that count as focus?
>
>  Would having the app place something into the field put focus on the
> field?
>
>  What I am really wondering is when it comes to the buttons can I leave
> them be because the text fields have code to save their info when the
> focus leaves or should I add code to the buttons to tell them after
> placing the info into the text field, save same info to an array?
>
>  Thanks.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Data Persistence

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 8/4/18 2:27 PM, John McKenzie via use-livecode wrote:
>   Thank you to the additional people who welcomed me. I contrast this
> with the time I asked a question on Usenet about a scripting language I
> was learning and the first reply told me I was awful (true, which is
> why I was asking questions) and to come back and only ask questions
> when I have the script I posted working.

Well that's a Catch-22 now, isn't it. We like to think we're better than
that. Please feel free to ask anything, even if you think it's stupid.
We've all been there. And besides, any mocking on the list usually turns
into a bad joke thread you'll be sorry you started. Conf.: "brains".

>   Would having the app place something into the field put focus on the
> field?
>
>   What I am really wondering is when it comes to the buttons can I leave
> them be because the text fields have code to save their info when the
> focus leaves or should I add code to the buttons to tell them after
> placing the info into the text field, save same info to an array?

Text-related field messages generally only trigger when a user
physically types into a field. Script-inserted text does not generate
those. You'll need to do a save after your handler changes the text,
which isn't a problem because you know when the script does it.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123