Re: Data Persistence
This is right. I do a similar thing, but I have a command I wrote that gets all
the objects on a card, excluding groups and fields that are in a datagrid, then
loops through each one for a property I set in them indicating the array key I
want to populate the field with. This way I can load data from a database as an
array, then populate all the fields on a card with the data from that array,
simply by virtue of adding a property to each field I want to populate.
This command I have, I call it populateForm, also populates buttons and popup
menus (which are actually buttons). A checkbox for instance can be populated
with one of the values, true, yes or 1. (yes because that is the default value
returned by a PDF fillable form when one of it's checkboxes is checked).
Bob S
> On Aug 15, 2018, at 17:26 , Brian Milby via use-livecode
> wrote:
>
>> on openstack
>> set the defaultFolder to specialFolderPath("cache")
>> put URL ("binfile:" & theflightArray) into theEncodedArray
>> put arrayDecode(theEncodedArray) into flightArr
>> put flightArr[1] into field flight of card 1
>> put flightArr[2] into field sta of card 1
>> put flightArr[3] into field ata of card 1
>> # Etc, etc, for each text field for each card
>> end openstack
>>
>> I see a few things already that make me think it is unlikely to be
>> that simple. Also the array probably needs a "[]" after it every time.
>> So it is probably embarrassingly wrong and I should spend a little more
>> time reading the dictionary before sending this off but I have to leave
>> for work in a few minutes.
>>
>> Thanks for your help.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
I don’t think you can count on the shutdown message, so you would export on
each change.
Arrays can use text for the key, so you could make things easier by using loops
and field names.
Thanks,
Brian
On Aug 15, 2018, 4:58 PM -0500, John McKenzie via use-livecode
, wrote:
>
>
> Hello again, everyone.
>
> Jacqueline, I enjoyed the fact you shared your story of not
> conforming to gender stereotypes with your childhood interests. Find it
> sad that science and engineering in general was (is?) considered a boys
> thing.
>
> Feel like I want to inject my two cents worth about software licences
> but it is a topic that could derail the list and I know I should not
> contribute to that. Know I was OK with and understood the off the cuff
> nature of "silly" and definitely do not agree with everything licences
> force upon us in modern times.
>
>
> So I continue to ask questions to help with my data persistence
> problem on Android.
>
> While I want to make sure my syntax is correct I firstly need to know
> if conceptually what I am doing will work/is correct.
>
> On my three cards (each records numbers for a different flight) the
> fields now all save their info to an array, flightArr[], upon
> closeField as suggested by the crowd here on the mailing list.
>
> I have it set-up so that when I stitch to another app (a phone call
> comes in, or I need to look up an airport code using an app, etc) it
> saves the info from each field on every card to a text file and upon
> opening it repopulates those text fields. This is accomplished using
> the handlers on shutdown and on openStack. The change I am going to try
> unless told not to in reply to this message is to encode the array into
> something and deencode it upon openStack.
>
> So each field would have put something into the array upon closeField.
>
> Would it work that upon on shutdown I could just say encode the array
> and then upon openStack I deencode the array and have the commands to
> populate the appropriate fields with their values from the array that
> was just deencoded?
>
> My array is called flightArr[]. Want to check with all of you that the
> syntax I was going to try is correct, although I suppose it does not
> matter if conceptually this is a bad idea. This would be on the stack.
>
> on shutdown
> set the defaultFolder to specialFolderPath("cache")
> put arrayEncode(flightArr) into theEncodedArray
> put theEncodedArray into URL ("binfile:" & theflightArray)
> pass shutdown
> end shutdown
>
> on openstack
> set the defaultFolder to specialFolderPath("cache")
> put URL ("binfile:" & theflightArray) into theEncodedArray
> put arrayDecode(theEncodedArray) into flightArr
> put flightArr[1] into field flight of card 1
> put flightArr[2] into field sta of card 1
> put flightArr[3] into field ata of card 1
> # Etc, etc, for each text field for each card
> end openstack
>
> I see a few things already that make me think it is unlikely to be
> that simple. Also the array probably needs a "[]" after it every time.
> So it is probably embarrassingly wrong and I should spend a little more
> time reading the dictionary before sending this off but I have to leave
> for work in a few minutes.
>
> Thanks for your help.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Hello again, everyone.
Jacqueline, I enjoyed the fact you shared your story of not
conforming to gender stereotypes with your childhood interests. Find it
sad that science and engineering in general was (is?) considered a boys
thing.
Feel like I want to inject my two cents worth about software licences
but it is a topic that could derail the list and I know I should not
contribute to that. Know I was OK with and understood the off the cuff
nature of "silly" and definitely do not agree with everything licences
force upon us in modern times.
So I continue to ask questions to help with my data persistence
problem on Android.
While I want to make sure my syntax is correct I firstly need to know
if conceptually what I am doing will work/is correct.
On my three cards (each records numbers for a different flight) the
fields now all save their info to an array, flightArr[], upon
closeField as suggested by the crowd here on the mailing list.
I have it set-up so that when I stitch to another app (a phone call
comes in, or I need to look up an airport code using an app, etc) it
saves the info from each field on every card to a text file and upon
opening it repopulates those text fields. This is accomplished using
the handlers on shutdown and on openStack. The change I am going to try
unless told not to in reply to this message is to encode the array into
something and deencode it upon openStack.
So each field would have put something into the array upon closeField.
Would it work that upon on shutdown I could just say encode the array
and then upon openStack I deencode the array and have the commands to
populate the appropriate fields with their values from the array that
was just deencoded?
My array is called flightArr[]. Want to check with all of you that the
syntax I was going to try is correct, although I suppose it does not
matter if conceptually this is a bad idea. This would be on the stack.
on shutdown
set the defaultFolder to specialFolderPath("cache")
put arrayEncode(flightArr) into theEncodedArray
put theEncodedArray into URL ("binfile:" & theflightArray)
pass shutdown
end shutdown
on openstack
set the defaultFolder to specialFolderPath("cache")
put URL ("binfile:" & theflightArray) into theEncodedArray
put arrayDecode(theEncodedArray) into flightArr
put flightArr[1] into field flight of card 1
put flightArr[2] into field sta of card 1
put flightArr[3] into field ata of card 1
# Etc, etc, for each text field for each card
end openstack
I see a few things already that make me think it is unlikely to be
that simple. Also the array probably needs a "[]" after it every time.
So it is probably embarrassingly wrong and I should spend a little more
time reading the dictionary before sending this off but I have to leave
for work in a few minutes.
Thanks for your help.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 < use-livecode@lists.runrev.com> 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 > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 , 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 > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 . 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
Re: Data Persistence
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
. 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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 , 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 > > 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 > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 > 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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 < use-livecode@lists.runrev.com> wrote: > Interesting... does it load the file database into memory? > > Bob S > > > > On Jul 30, 2018, at 08:19 , Mike Bonner via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as > dbname > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Interesting... does it load the file database into memory? Bob S > On Jul 30, 2018, at 08:19 , Mike Bonner via use-livecode > wrote: > > Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as dbname ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 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 wrote: > >> Yes >> > >> On Mon, Jul 30, 2018 at 8:45 AM Bob Sneidar via use-livecode < >> use-livecode@lists.runrev.com> 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 < >>> use-livecode@lists.runrev.com> 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 >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >>> >> ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 wrote: > Yes > > On Mon, Jul 30, 2018 at 8:45 AM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> 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 < >> use-livecode@lists.runrev.com> 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 >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Yes 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 < > use-livecode@lists.runrev.com> 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 > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 > 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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 > 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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 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 ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
On 07/27/2018 02:58 PM, Mike Bonner via use-livecode wrote: Your Bran. will be assimilated. (borg zombies FTW) Yes. More brains please. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Use case is a major driver though. If you have no need to hand edit a
file, then LSON is an efficient and easy way to store the data. It also
has the benefit of being able to easily store binary data if needed.
On Fri, Jul 27, 2018 at 5:40 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Alex Tweedly wrote:
>
> On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote:
>>
>>>
>>> > Using arrays intigues me, especially if I can just keep it in RAM (It
>>> > is a small amount of data for sure).
>>>
>>> One great thing about LC's built-in support for arrays is that it's
>>> built-in.
>>>
>>> JSON has become used in so many other languages that we've forgotten why
>>> it was invented: to serialize JavaScript objects as simply and efficiently
>>> as possible using features already built into the JavaScript interpreter.
>>>
>>> LSON is that for us, as much a with-the-grain approach to data handling
>>> in LiveCode as JSON is for JavaScript.
>>>
>> I just wish there was a human-readable, human-editable-in-a-text-editor
>> variant of LSON :-)
>>
>
> True, LSON is even closer to BSON ("Binary JSON") than JSON itself, with
> all the machine-parsing efficiencies inherent in a binary format.
>
> The world wanted a human-readable/writable form of JSON too, so YAML was
> invented. :)
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
>
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Sannyasin Brahmanathaswami wrote: > Richard wrote " If that native form is an array, there may be no need > to do anything more than what LC already gives us straight out of the > box." > > I have been toying with this for some time, but like Alex said.. > > "I just wish there was a human-readable, human-editable-in-a-text- > editor variant of LSON :-)" > > Keeps me in JSON How often do you hand-edit array data? Even JSON was found too cumbersome for efficient human reading/writing, so YAML came along to fill that gap where human editing of raw data is a priority. One of the great things about computing in the 21st century is that we have so many options to choose from, selecting the best fit for the balance of human editing vs runtime efficiency as a given project requires. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Alex Tweedly wrote:
On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote:
> Using arrays intigues me, especially if I can just keep it in RAM (It
> is a small amount of data for sure).
One great thing about LC's built-in support for arrays is that it's
built-in.
JSON has become used in so many other languages that we've forgotten
why it was invented: to serialize JavaScript objects as simply and
efficiently as possible using features already built into the
JavaScript interpreter.
LSON is that for us, as much a with-the-grain approach to data
handling in LiveCode as JSON is for JavaScript.
I just wish there was a human-readable, human-editable-in-a-text-editor
variant of LSON :-)
True, LSON is even closer to BSON ("Binary JSON") than JSON itself, with
all the machine-parsing efficiencies inherent in a binary format.
The world wanted a human-readable/writable form of JSON too, so YAML was
invented. :)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
ambassa...@fourthworld.comhttp://www.FourthWorld.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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. 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. The affects and requirements would be similar. Update the array, (1 update) ecode and write to disk (second update) vs update in mem sqlite, and update attached sqlite database. Does my thinking make sense? On Fri, Jul 27, 2018 at 4:11 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> 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. And since > you can convert the array to a memory sqLite database and back again with > my handy dandy handlers, everybody wins! > > Bob S > > > > On Jul 27, 2018, at 12:52 , Alex Tweedly via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote: > > > >> > >> > Using arrays intigues me, especially if I can just keep it in RAM (It > >> > is a small amount of data for sure). > >> > >> One great thing about LC's built-in support for arrays is that it's > built-in. > >> > >> JSON has become used in so many other languages that we've forgotten > why it was invented: to serialize JavaScript objects as simply and > efficiently as possible using features already built into the JavaScript > interpreter. > >> > >> LSON is that for us, as much a with-the-grain approach to data handling > in LiveCode as JSON is for JavaScript. > > I just wish there was a human-readable, human-editable-in-a-text-editor > variant of LSON :-) > > > > Someday, when I have some spare time, ... > > > > -- Alex. > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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. And since you can convert the array to a memory sqLite database and back again with my handy dandy handlers, everybody wins! Bob S > On Jul 27, 2018, at 12:52 , Alex Tweedly via use-livecode > wrote: > > On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote: > >> >> > Using arrays intigues me, especially if I can just keep it in RAM (It >> > is a small amount of data for sure). >> >> One great thing about LC's built-in support for arrays is that it's built-in. >> >> JSON has become used in so many other languages that we've forgotten why it >> was invented: to serialize JavaScript objects as simply and efficiently as >> possible using features already built into the JavaScript interpreter. >> >> LSON is that for us, as much a with-the-grain approach to data handling in >> LiveCode as JSON is for JavaScript. > I just wish there was a human-readable, human-editable-in-a-text-editor > variant of LSON :-) > > Someday, when I have some spare time, ... > > -- Alex. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Your Bran. will be assimilated. (borg zombies FTW) On Fri, Jul 27, 2018 at 3:39 PM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > On 7/27/18 12:47 PM, John McKenzie via use-livecode wrote: > > Tom, thank you for welcoming me. Much different than some online > > programming groups. :-) > > We love new users, it's more brains for the collective. :) > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
On 7/27/18 12:47 PM, John McKenzie via use-livecode wrote: Tom, thank you for welcoming me. Much different than some online programming groups. :-) We love new users, it's more brains for the collective. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Richard Gaskin This is where serialization comes in, collecting all the disparate pointer contents and packing them into a bytestream that can be saved or transported, using arrayEncode: Ha! I knew that would bring out something useful... thanks for upgrading the handlers. Richard wrote " If that native form is an array, there may be no need to do anything more than what LC already gives us straight out of the box." I have been toying with this for some time, but like Alex said.. "I just wish there was a human-readable, human-editable-in-a-text-editor variant of LSON :-)" Keeps me in JSON BR ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote: > Using arrays intigues me, especially if I can just keep it in RAM (It > is a small amount of data for sure). One great thing about LC's built-in support for arrays is that it's built-in. JSON has become used in so many other languages that we've forgotten why it was invented: to serialize JavaScript objects as simply and efficiently as possible using features already built into the JavaScript interpreter. LSON is that for us, as much a with-the-grain approach to data handling in LiveCode as JSON is for JavaScript. I just wish there was a human-readable, human-editable-in-a-text-editor variant of LSON :-) Someday, when I have some spare time, ... -- Alex. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Sannyasin Brahmanathaswami wrote:
> (rough draft code)
>
> Local sTempParamArray # may good to save a local,
>
> Command saveTempParams
>
>Put fld "fuelNeed" into pTempParamArray["fuelNeeded'}
>Put fld "timeToArrival" into pTempParamArray["timeToArrival""
># etc.
>Put pTempParamArray into sTempParamArray
>storeTempParams pTempParamArray
>
> End saveTempParams
>
> command storeTempParams pTempParamArray
>
> put specialFolderPath("documents") & "/tempSavedParams" into
tSavedPath
>put sTempParamArray into url ("binfile:" & tSavedPath)
>
> end storeTempParams
A good outline, but missing a key step: arrays are collections of
pointers and in their native form are not a contiguous bytestream, so
attempting to write one to disk directly with yield an empty file.
This is where serialization comes in, collecting all the disparate
pointer contents and packing them into a bytestream that can be saved or
transported, using arrayEncode:
command storeTempParams pTempParamArray
put specialFolderPath("documents") & "/tempSavedParams" into \
tSavedPath
put arrayEncode(sTempParamArray) into url ("binfile:" & tSavedPath)
end storeTempParams
And because arrayDecode will throw a fatal error if you attempt to use
it with anything other than actual LSON data, we can't just check "the
result" afterward; better to wrap it in a try/catch:
Function getTempSavedParams
Put specialFolderPath("documents") & "/tempSavedParams" into \
tSavedPath
put url ("binfile:" & tSavedPath) into pTempParamArray
-- Always check I/O for errors:
if the result is empty then
return "Error in getTempSavedParams: "& the result for error
end if
-- Try as LSON:
try
put arrayDecode(pTempParamArray) into pTempParamArray
catch tErr
return "Not a valid array file: "& tSavedPath for error
end try
--
return pTempParamArray
end getTempSavedParams
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
ambassa...@fourthworld.comhttp://www.FourthWorld.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
John McKenzie wrote: > 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. Buzzwords are important. If you don't use enough of them you'll never find adequate funding. :) > Using arrays intigues me, especially if I can just keep it in RAM (It > is a small amount of data for sure). One great thing about LC's built-in support for arrays is that it's built-in. JSON has become used in so many other languages that we've forgotten why it was invented: to serialize JavaScript objects as simply and efficiently as possible using features already built into the JavaScript interpreter. LSON is that for us, as much a with-the-grain approach to data handling in LiveCode as JSON is for JavaScript. ELSON and any number of other variants can be fun, but what will you do with the deserialized native form as you work with it in your program? If that native form is an array, there may be no need to do anything more than what LC already gives us straight out of the box. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Welcome John!
You will need this, I would endorse Tom's arrayEncode.
If you have not: Learn to array code RIGHT NOW, before going further with
Livecode. I resisted array for years, and it bought me a boat load of silly
coding of text files. And 100 of lines of unnecessary code then I are
learned about arrays. I broke my head of the desk.. saying "oh wow is me! I
have could have saved thousand of hours and lines of codes if use arrays from
the beginning!" (ha)
(rough draft code)
Local sTempParamArray # may good to save a local,
Command saveTempParams
Put fld "fuelNeed" into pTempParamArray["fuelNeeded'}
Put fld "timeToArrival" into pTempParamArray["timeToArrival""
# etc.
Put pTempParamArray into sTempParamArray
storeTempParams pTempParamArray
End saveTempParams
command storeTempParams pTempParamArray
put specialFolderPath("documents") & "/tempSavedParams" into
tSavedPath
put sTempParamArray into url ("binfile:" & tSavedPath)
end storeTempParams
# you will have some trigger get them back, I don't know what that would be:
Function getTempSavedParams
Put specialFolderPath("documents") & "/tempSavedParams" into
tSavedPath
put url ("binfile:" & tSavedPath) into pTempParamArray
put pTempParamArray into sTempParamArray
return pTempParamArray
end getTempSavedParams
command reLoadSettings
put getTempSavesParams() into pLastParams
put pLastParams["fuelNeeded"] into # whatever
put pLastParams["timeToArrival"] into # whatever
# etc.
End reLoadSettings
# code is a little verbose but easy to debug later.
# other wizards can improve on my baby xTalk
BR
On 7/23/18, 11:57 AM, "use-livecode on behalf of John McKenzie via
use-livecode" wrote:
What I need help with is the issue of persistence.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
John McKenzie wrote: > An SQLite database seems like extreme overkill but I will give it > a try if it is needed to get the app to work. SQLite is very feature-rich, but if you don't need the relationality provided by a full-featured RDBMS it can be like swatting flies with a grenade launcher. Persistence can be provided by any format that can be written to disk. You may be surprised by how many programs use simple flat text files. And in LC, arrays are easy and efficient to work with, and can be serialized to disk with arrayEncode (resulting in files I affectionately call "LSON", a LiveCode-optimized alternative to the JavaScript-optimized JSON). Indeed, many who use an RDBMS write code to return the result of queries in the form of an LC array. If you don't need the relationality, and if your data is of a size that fits comfortably in RAM, using an array directly is about as simple as it can be. If your data does not fit comfortably in RAM, you may find that breaking it into multiple LSON files can work quite nicely. > Does this require me to pre-install any sort of database software? Selecting the SQLite driver in the Standalone Build should be all that's needed. > Brian, I gathered from your post that the only way to work with a > text file as data storage on Android is to save every time a field > is changed? How would I do this in such a way that it knows to save > when "1421" is typed as a time of day as opposed to the app trying > to save it after "1" is typed, then again when "2" is typed, etc. > Or perhaps there is no way and I have to re-save every time a > character it typed. Finding appropriate auto-save triggers is the third hard thing in computing (the first two being cache invalidation and naming things ). Saving on every keystroke may be overkill. Saving on closeField may suffice when the contents of each field do not contain much data. If you have a long field in which a user may spend significant time, you may consider a periodic timer for saving as a middle path between closeField and textChanged. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Hi John, > Am 27.07.2018 um 19:47 schrieb John McKenzie via use-livecode > : > > Tom, thank you for welcoming me. Much different than some online > programming groups. :-) > > Brian and Tom thank you for your replies about my Android data > persistence problem. An SQLite database seems like extreme overkill but > I will give it a try if it is needed to get the app to work. Does this > require me to pre-install any sort of database software? nope, unlike batteries, everything is included in LC! :-) > Brian, I gathered from your post that the only way to work with a text > file as data storage on Android is to save every time a field is > changed? How would I do this in such a way that it knows to save when > "1421" is typed as a time of day as opposed to the app trying to save > it after "1" is typed, then again when "2" is typed, etc. Or perhaps > there is no way and I have to re-save every time a character it typed. Save "on closefield", means when the user has finished typing and "leaves" the field. > I am super duper busy this week, especially this weekend. Will really > get back to the problem in earnest next week. Whatever... :-) Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
Tom, thank you for welcoming me. Much different than some online programming groups. :-) Brian and Tom thank you for your replies about my Android data persistence problem. An SQLite database seems like extreme overkill but I will give it a try if it is needed to get the app to work. Does this require me to pre-install any sort of database software? Brian, I gathered from your post that the only way to work with a text file as data storage on Android is to save every time a field is changed? How would I do this in such a way that it knows to save when "1421" is typed as a time of day as opposed to the app trying to save it after "1" is typed, then again when "2" is typed, etc. Or perhaps there is no way and I have to re-save every time a character it typed. I am super duper busy this week, especially this weekend. Will really get back to the problem in earnest next week. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
welcome john.just as a tiparrayencode is very handy for saving whatever you needyou can always also use a sqlite database to store data and load / refresh whenever you needit also also works as in-memory database. On Mon, Jul 23, 2018 at 6:21 PM, Brian Milby via use-livecode < use-livecode@lists.runrev.com> wrote: > I built a time tracking app that had the same type of persistence > requirement. I used a text file for the data store. Each time any field had > a change, the data was saved again. When loading the app it would import > the current data. Data was only cleared on request (and I would only allow > that after it was emailed). When cleared, I deleted the file. > > As you have discovered, on mobile your app can be terminated at any time > and you may not be given a chance to save data before then. > > My test was on iOS but it should work the same on Android. > > Thanks, > Brian > On Jul 23, 2018, 4:58 PM -0500, John McKenzie via use-livecode < > use-livecode@lists.runrev.com>, wrote: > > > > > > Hello, all. > > > > I am new to Livecode development but not computing. When I heard of > > something that was inspired by Hypercard I had to know more. Used > > Livecode to make a little app on my phone for work but the level of > > interest this app generated now make me want to finish it, and maybe > > even share and/or sell it. Livecode is pretty cool and I am looking > > forward to learning how to use it and do stuff with it. > > > > So my first (and I sadly suspect not last) question to the list is > > about persistence on the Android platform. > > > > My job is in the aviation industry. For now I want to get it working. > > Then I will polish it off, beta test it, etc. One airline rep gave me > > his card and said to call him about it if I wanted to sell it. > > > > The get it working part is where I need your help. I was unclear on > > what Livecode could and could not do so I emailed them and a very > > helpful person named Heather educated me a bit. Now that I know it > > might work for my application I would appreciate your help in getting > > it working. > > > > Right now it will be an Android app. iOS app later probably. > > > > The app is to help me record times and other facts about plane > > landings (like when the plane landed and how much fuel is requested by > > the Captain). At the end of a flight I can press a button and an email > > addressed to our operations centre is auto-populated in the body of the > > text with these numbers. For example if I press the button labelled > > "ATA" (actual time of arrival) it places the current time in the text > > field next to the ATA button. I can touch the text field and edit the > > time if need be. > > > > What I need help with is the issue of persistence. If I get an SMS > > message, a phone call or an alarm goes off the data will be wiped out > > when I return to the app. Sometimes if I leave the app to check > > something else and come back the data is there and other times the text > > fields are all blank. Tried saving the data in a text file and having > > the app load it up each time it starts. Most of the time this does not > > work. Usually when I start the app up again at the beginning of the > > next shift it starts up with the times of yesterday's flight. > > > > > > So I would like to know how to properly hold the data so the entries > > in the text fields are still there when I go to another app then come > > back to mine. looking to have basic persistence in my app. > > > > Guidance on the (or one of the) proper way(s) to accomplish this > > would be most appreciated. > > > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data Persistence
I built a time tracking app that had the same type of persistence requirement. I used a text file for the data store. Each time any field had a change, the data was saved again. When loading the app it would import the current data. Data was only cleared on request (and I would only allow that after it was emailed). When cleared, I deleted the file. As you have discovered, on mobile your app can be terminated at any time and you may not be given a chance to save data before then. My test was on iOS but it should work the same on Android. Thanks, Brian On Jul 23, 2018, 4:58 PM -0500, John McKenzie via use-livecode , wrote: > > > Hello, all. > > I am new to Livecode development but not computing. When I heard of > something that was inspired by Hypercard I had to know more. Used > Livecode to make a little app on my phone for work but the level of > interest this app generated now make me want to finish it, and maybe > even share and/or sell it. Livecode is pretty cool and I am looking > forward to learning how to use it and do stuff with it. > > So my first (and I sadly suspect not last) question to the list is > about persistence on the Android platform. > > My job is in the aviation industry. For now I want to get it working. > Then I will polish it off, beta test it, etc. One airline rep gave me > his card and said to call him about it if I wanted to sell it. > > The get it working part is where I need your help. I was unclear on > what Livecode could and could not do so I emailed them and a very > helpful person named Heather educated me a bit. Now that I know it > might work for my application I would appreciate your help in getting > it working. > > Right now it will be an Android app. iOS app later probably. > > The app is to help me record times and other facts about plane > landings (like when the plane landed and how much fuel is requested by > the Captain). At the end of a flight I can press a button and an email > addressed to our operations centre is auto-populated in the body of the > text with these numbers. For example if I press the button labelled > "ATA" (actual time of arrival) it places the current time in the text > field next to the ATA button. I can touch the text field and edit the > time if need be. > > What I need help with is the issue of persistence. If I get an SMS > message, a phone call or an alarm goes off the data will be wiped out > when I return to the app. Sometimes if I leave the app to check > something else and come back the data is there and other times the text > fields are all blank. Tried saving the data in a text file and having > the app load it up each time it starts. Most of the time this does not > work. Usually when I start the app up again at the beginning of the > next shift it starts up with the times of yesterday's flight. > > > So I would like to know how to properly hold the data so the entries > in the text fields are still there when I go to another app then come > back to mine. looking to have basic persistence in my app. > > Guidance on the (or one of the) proper way(s) to accomplish this > would be most appreciated. > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data persistence in iOS apps
With iOS you have to save a copy of the stack into the documents folder, and then jump into that stack. Then changes can be saved. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data persistence in iOS apps
Colin, thanks As I suspected: but when I put my data stack into the bundle via 'Copy Files' in the Standalone Settings, it doesn't go into Documents, does it? This copy is in effect just as read-only as the Splash stack. I guess I have to do something like: - check if the data stack is in the documents folder (i.e. has it ever been saved?) - if not, save it immediately, before any activity in the app. Thereafter one can update it as appropriate (at quit, or every time it changes - not sure which is the best policy). Graham On Thu, 19 Apr 2012 09:32:52 -0400, Colin Holgate co...@verizon.net wrote: With iOS you have to save a copy of the stack into the documents folder, and then jump into that stack. Then changes can be saved. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data persistence in iOS apps
On 4/19/12 12:14 PM, Graham Samuel wrote: As I suspected: but when I put my data stack into the bundle via 'Copy Files' in the Standalone Settings, it doesn't go into Documents, does it? This copy is in effect just as read-only as the Splash stack. Right, the whole engine folder is read-only. The copy files pane in the standalone builder puts files into the engine folder. I guess I have to do something like: - check if the data stack is in the documents folder (i.e. has it ever been saved?) - if not, save it immediately, before any activity in the app. Thereafter one can update it as appropriate (at quit, or every time it changes - not sure which is the best policy). I usually update on quit (shutdown) but I don't think it matters which you choose. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Data persistence in iOS apps
On Apr 19, 2012, at 1:36 PM, J. Landman Gay wrote: On 4/19/12 12:14 PM, Graham Samuel wrote: Thereafter one can update it as appropriate (at quit, or every time it changes - not sure which is the best policy). I usually update on quit (shutdown) but I don't think it matters which you choose. It matters if it crashes or the power fails. Unless I'm in a hurry, I tend to save after every change. Maybe this isn't as much of a consideration in a handheld, but I have unattended systems out in the field taking data. Onward, Jerry ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
