Problem: lack of volatile storage

[yrashk]

There are certain cases, like in-memory indexing or testing, where NOT storing data to disc between restarts would have been useful.

(Also, MUMPS has this distinction as well in a form of volatile and global variables.)

Proposed solution: introduce WRITE/VOLATILE and READ/VOLATILE (or, say, WRITE*/READ*) transactions. This way one one can use all storage-related functionality interchangeably.

[omarkj]

Hi Yurii,

This sounds interesting to me, but I'm trying to understand when this would be useful. Is this something similar to temporary tables in SQL? If so, a transaction-scoped variables would basically accomplish this.

[yrashk]

The utility I can see is primarily in-memory indices (those are bloody fast), with the volatility borders at the server restarts.

[tsafin]

There are different levels of persistency in GT.M and Caché, which kind of volatile memory did you mean here? Globals vs local? Globals under transaction scope and outside

[tsafin]

(sorry for partial comment, got disconnected in the subway)
There are also semi-persistent globals mapped to volatile in memory database. So which kind of nonvolatile primitive did you mean here?

[yrashk]

Here I meant something similar to globals mapped to volatile in memory database, adjusted for specificity of PumpkinDB primitives

…

On Mar 28, 2017 12:30 AM, "Timur Safin" ***@***.***> wrote: (sorry for partial comment, got disconnected in the subway) There are also semi-persistent globals mapped to volatile in memory database. So which kind of nonvolatile primitive did you mean here? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#197 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAABxDgamGHJrO71pdlEM89ioRHZad6kks5rqLcOgaJpZM4MkkNv> .