[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: SQLite for temp tables

Status
Not open for further replies.
D

dbeavon

Guest
There are a few nice things that could be gained by interacting with SQLite, and storing data from ABL. One is the ability to post-analyze the data using SQL queries. This is something that is pretty far outside the scope of anything we can do with ABL temp-tables. But another thing that could be gained is simply the ability to store a local, *persistent* copy of our data (eg. a copy that lives on a PASOE server ). I wonder if "persistence" is is something that could be added to the implementation of ABL temp-tables and prodatasets in ABL? Before continuing to talk about "persistent" temp-tables, I should point out how costly it can be to read and process large amounts of OpenEdge data over client-server. For example, it takes a long time to read all of our open sales orders using an ABL business layer, and then combine them with related information from master tables (products, customers, salespersons, etc). The bulk of the cost can be attributed to the time-consuming network chatter that takes place between the ABL session and the remote database. But what if the resulting temp-tables could be made *persistent* (shared) and copied between multiple ABL sessions within an msagent? That persistent data could be stored for whatever span of time is appropriate. These types of temp-tables could then be used as a type of cache, and would substantially improve performance for any clients of PASOE. Certain master tables (eg products, customers) might never need to be refreshed for an entire day - if the information was persistent and the source data was wasn't being actively modified . In order to make temp-tables persistent, the best approach (today) is to serialize to disk (perhaps by using EXPORT statements or WriteXml). But this becomes expensive when a large amount of data is de-serialized because it needs to be parsed, and re-indexed, and re-loaded into the memory of every other ABL session that might need the same data. Instead of jumping thru these hoops to perform serialization and deserialization, it would be more expedient if an ABL session could simply *attach* (bind) itself to some pre-existing temp-table files on the local SSD. This would give us a way to retrieve the costly client-server data only once - and then re-use it numerous times (by independent sessions in the msagent). I see that there are startup options to preserve the temp files used by ABL sessions ... . documentation.progress.com/.../index.html ... but I've never heard if there is a way to copy or reattach (bind) these files as static temp-tables in a new session. Has anyone tried to accomplish something like this in ABL? This type of a feature would provide a subset of the benefits of an embedded database (like SQLite). (PS. I think another approach for keeping persistent temp-table data might be to use "state-aware" sessions that hold onto their own temp data for long periods of time. Those would then serve up the data to other sessions as needed. The problem in this case is still the cost that is involved in marshalling data from the state-aware session to another session where the temp data would be reused. The marshalling would be costly. It would be much better if data would simply persist to local disk and anyone could attach to it instantly!)

Continue reading...
 
Status
Not open for further replies.
Top