I saw an interesting project: https://github.com/JuliaLang/julialang.github.com/blob/master/gsoc/2015/index.md#project-simple-persistent-distributed-storage "This project proposes to implement a very simple persistent storage mechanism for Julia variables so that data can be saved to and loaded from disk with a consistent interface that is agnostic of the underlying storage layer."
["time-stamped versioning" - meaning? Schema evolution was one purported downside to:] This SoC project may or may not be necessary. That is, be agnostic and just a wrapper/API. What about implementing (the very small system) Prevayler in Julia? I've seen it ported to some languages but since I heard about it in 2001, I can't say it has taken the world by storm (do not know anyone who uses it..). Business types and banks, etc. are very conservative and cling to SQL.. https://en.wikipedia.org/wiki/Prevayler "Prevayler requires enough RAM to keep the entire system state." This was perceived as a drawback at the time.. Lot's of databases fit, now (and in the future). This seems the requirement anyway in HPC. You do not want to work on virtual memory.. Is there a reason Prevayler can't be done in Julia? I do not think so. Julia has types not OO in the conventional sense and I'm not sure it's an issue. If I recall, the only requirement was that objects must be able to serialize. I only know it's not appropriate for PHP (because of "no state"). At least look at this article from the horses mouth: http://www.advogato.org/article/398.html "Transparent Persistence, Fault-Tolerance and Load-Balancing for Java Systems. Orders of magnitude FASTER and SIMPLER than a traditional DBMS. No pre or post-processing required, no weird proprietary VM required, no base-class inheritance or clumsy interface definition required: just PLAIN JAVA CODE. [..] Question: RAM is getting cheaper every day. Researchers are announcing major breakthroughs in memory technology. Even today, servers with multi-gigabyte RAM are commonplace. For many systems, it's already feasible to keep all business objects in RAM. Why can't I simply do that and forget all the database hassle? Answer: You can, actually. [..] If all my objects stay in RAM, will I be able to use SQL-based tools to query my objects' attributes? No. You will be able to use object-based tools. The good news is you will no longer be breaking your objects' encapsulation." I thought it might be a dead project but seems not: https://github.com/jsampson/prevayler/tree/master "authored on Aug 12, 2014" There was some controversy at the time: http://c2.com/cgi/wiki?ThePrevayler "Orders of magnitude faster and simpler than a traditional database. Write plain java classes (albeit in accordance with a CommandPattern and a few constraints): [..] no inheritance from base-class required. Clear documentation and demo included. 3251 times faster than MySQL. 9983 times faster than ORACLE." "Aren't you simply dropping all code from DBMs and stuffing it all on the application? No. I have seen prevalent systems that were thousands of lines of code. Most DBMs are hundreds of thousands of lines of code. --KlausWuestefeld" [This one I didn't know..:] "KentBeck, [..] and KlausWuestefeld paired up for a weekend in december 2002, on the island of Florianopolis, Brazil, and implemented Florypa, a minimal prevalence layer for Smalltalk (VisualWorks) based on Prevayler." "After having testing Prevayler (and Prevayler-like IMDB's) we came to this conclusion: It is useful for prototyping, but fails miserabely in terms of a lot of OODBMS/RBMS issues. In fact, we concluded that when all the problems with Prevayler was solved, we had an object-oriented database. * Sounds like an OOP version of GreencoddsTenthRuleOfProgramming." http://c2.com/cgi/wiki?GreencoddsTenthRuleOfProgramming A database-oriented twist on GreenspunsTenthRuleOfProgramming in which, "Every sufficiently complex application/language/tool will either have to use a database or reinvent one the hard way." I don't know who originally said it, so I combined DrCodd's name with Greenspuns'. Ironically, even Lisp, the original "greenspun" language, reinvents one by having an internal complex data structure (nested list in byte-code form) that takes on database-like characteristics. http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp." as Julia has Lisp-like macros, considered a "lisp" by some, I think this "rule" may not apply too well to Julia..
