solved Communicating an array across AJAX boundaries

TiG
TiG
@tig
7 years ago
184 posts
Have a need to retain an associative array generated in response to a user request for use in another (highly related but technically independent) view. (The array in this case holds recent comment ids of interest per discussion.) Albeit only essential information, this is too big for temp vars or cookies.

This array will be regenerated (and re-stored) based on another mechanism so the timeliness is already addressed. Just need a way to store and retrieve.

Note: I could store this in the db (since that is of course global to all sessions) as a JSON stream but I would rather communicate the array in-memory to avoid db activity and further processing (JSON). Caching might be an option but that seems to be a misuse of cache.


--
TiG

updated by @tig: 02/11/18 08:58:28AM
michael
@michael
7 years ago
7,748 posts
For storing things and moving them around during a single page load my first idea would be to see if a flag would work:
$_stuff = array(
 'things' => 'some things',
 'bits' => 'and pieces'
);
jrCore_set_flag('some_key', $_stuff);
// then later somewhere else
$_stuff = jrCore_get_flag('some_key');

But you're wanting to save it over to a different page, so flags aren't going to be useful, my first thought for this scenario is:
jrCore_set_temp_value('xxYourModule', 'some_key', $_stuff);
// then later somewhere else
$_stuff = jrCore_get_temp_value('some_key');

But you're not wanting to use the database. How would you like to do it outside of the jamroom system?
TiG
TiG
@tig
7 years ago
184 posts
@michael

Thanks for weighing in.

I implemented this by storing a JSON encoded stream in the jrUser datastore. (I have more data than a flag will support.) This was the only sensible option I could think of given the circumstances. I posted the question just to see if there was something that I was not aware of. I dislike the overhead of the db access (and even the JSON) and would have preferred to -in effect- bind an in-memory array to a global variable that is reliable for a given user across sessions. This information (the array) will be routinely regenerated (it is algorithmically invalidated) thus I just need a global mechanism that works most of the time. I could store an index and if that index does not exist I will regenerate.

That is why I mentioned the cache. I could cache the array once generated and allow the 'client' to pull from the cache. Seems slimy (as a purist) but it probably would work.

My defacto solution (using the jrUser datastore) works. Just want to ensure I am not missing something. :)

As always, your advice is highly valued.


--
TiG
michael
@michael
7 years ago
7,748 posts
Stored in memory across sessions, yup that's a difficult ask. :p

The jrCore_get_temp_value() function set do not have a cache system built into it, so it will be accessing the db for each request.

A quick look for functions that do have a caching system in them turned up this one from the jrBanned module that might be useful to you:


/**
 * Get current banned config for a given ban type
 * @param $type string
 * @return bool|mixed|string
 */
function jrBanned_get_banned_config($type)
{ if (!is_array($type)) { $type = array($type); } $key = "jrbanned_is_banned_" . json_encode($type); if (!$_rt = jrCore_get_flag($key)) { if (!$_rt = jrCore_is_cached('jrBanned', $key, false, false)) { $tbl = jrCore_db_table_name('jrBanned', 'banned'); $req = "SELECT ban_type AS t, ban_value AS v FROM {$tbl} WHERE ban_type IN('" . implode("','", $type) . "')"; $_rt = jrCore_db_query($req, 'NUMERIC'); if (!$_rt || !is_array($_rt)) { $_rt = 'no_items'; } jrCore_set_flag($key, $_rt); jrCore_add_to_cache('jrBanned', $key, $_rt, 0, 0, false, false); } } if (!$_rt || !is_array($_rt) || count($_rt) === 0) { // No items of this type return false; } return $_rt; }

What its doing is checking if there is a flag ( IN MEMORY ), if no, check if there is a cached item ( FILESYSTEM / MEMORY ), if not, get it from the database ( DATABASE ).

So if its a performance issue reason you want to bypass the database, that structure looks about as good as you could get i reckon. Adjust as needed for your own module and situation.
TiG
TiG
@tig
7 years ago
184 posts
@michael

That provides the confirmation I need. Thanks again.


--
TiG

Tags