StartingPoints

Want to know what's new on the Wiki? Check RecentChanges --StefanReich

"Although I'm not using the prevayler code, I've come up with a very similar approach during design and development of a simple medical hardware application. The requirement was to keep a database of patient data consisting of personal data, test sessions and test results.

It all ended up living in the RAM. Our average customer's office worth of data for this application fits comfortably (in text file form) on a 1.4MB diskette, so it was more than obvious not to have anything to do with files -- the whole database is read from the (hand-modifiable, if need be) text file on startup, and is then saved as a whole whenever the patient file is closed. A command log is in the works, and -- given the database's almost negligible size -- the command log will be the only and ultimate way of storing the database -- yup, without any kind of persistent snapshot.

Internally, I ended up implementing quite a few concepts of object prevalence. Right now I'm cleaning up the client code/business command separation.

Although I've got to know the prevayler project only as of today, I've managed to implement almost the same thing. It took me almost half a year of deep thinking about how to do that, I admit. Nicely enough, the database was the last thing to be done in that partiular app. Given enough thought, the prevalent objects idea -- to me -- seems the only clean-cut way to manage data without having a dozen layers between your client, your business logic, and your data. It's a 13k line C++ application (using Qt) that manages its data in an ACID clean way, talks to the hardware (about 35% of the code is the hardware interfacing code), and provides a user interface for all that. Doing it 'the obvious way' would require at least bundling a hefty embedded database library, or using MySQL for simplicity's sake. After some conservative estimates I come to the conclusion that object persistence interfacing to an SQL data storage thing (RDBMS, whatever) would take more time to cleanly implement and debug, than just going with the object prevalence. I even went as far to give GigaBase a test run for about two week. Even though it was much easier to use than your typical parsed query based system, it still looked very hackish.

All in all, it's a neat concept, it has allowed me to keep the code clean and extremely simple (even in C++ with Qt), and is something that should be taught in computer science database courses, on par with classic RDBMS theory and practice. I admit that, in fact, it may only be the lack of formal CS education on my part that gave me a clean-enough horizon to actually live happily (and without prejudice) with object prevalence."

--KubaOber, a freelance developer

kk

I think it was a mistake to not have the wiki be prevalent during the Slashdot inundation a few days ago.  Everybody on Slashdot was making fun of how quickly your own server died.

--Carl Youngblood, computer programmer


Yep, quite unfortunate. Everyone assumed that the site was being run by a prevalence engine. Which was an incorrect assumption to make.

Oh well. a lot of people on slashdot are still attached to their database.

64 bit cpu's and hopefully a serious decrease in ram costs will see most systems using some sort of prevalence engine