Slashdot Mirror
Prevayler Quietly Reaches 2.0 Alpha, Bye RDBMS?
"We've used relational databases for years despite incompatibilities in SQL implementation. Accessing them from an OOP paradigm has been so tedious, that Object-Relational mapping technologies have sprouted all over the Open Source landscape. Some competing examples and models are Hibernate, OJB, TJDO, XORM, and Castor; which in turn have supporting frameworks such as Spring and SQLExecutor. Because SQL is the dominant form of interfacing with the data in an RDBMS, there's now a specification to offer it a friendlier OO face.
Most of the above, including the SQL-variants, arguably appear to add yet another layer of complexity (even if only at the integration level) where they should be taking complexity away. These solutions are put together by some very smart people, but it's inescapable to get that feeling someone is missing the forest (simple answer) because all the trees (incompatible models) are in the way. If there are so many after-the-fact solutions attempting to simplify relational database access and manipulation from OO, isn't it reasonable to think that there is something generally wrong with trying to cobble-together two disparate concepts with what are essentially high-caliber hacks? Is Prevayler a better way?"
I, for one, welcome our new object-oriented relational database managment systems overlords!
Is that really possible? How do you even benchmark that?
Richard "DataBase" M. Stallman needs a break.
Sounds like harassment to me.
Call your EU member!
Given enough time, I suppose this particular implementation will Prevayl
I'm all for trying to use Slashdot to promote your pet project, but don't couch your story in questions about people's use of your admittedly relatively unknown software.
taken! (by Davidleeroth) Thanks Bingo Foo!
This would be great for projects where interoperability isn't an issue or only occurs via edge connections like SOAP. However, I generally would be wary of a "database" which is only accessible in Java, via unique interface. What do you do with your Crystal Reports users? How do I get this into data cubes for analysis?
Frankly, this is simply a persistance layer with some nice properties. It *isn't* a database. A database stands at the center of your applications and makes itself available to as wide of an audiance as possible. It shouldn't limit your choice of tools in such an absurd manner.
Sig under construction since 1998.
Breakfast served all day!
What's so complicated about OO with RDMS? Just use EJB or buy/write your own object relation mapping library. This is a crock. I predict object oriented databases will fizzle and die in 3 days.
1st known failed CIA coup in South America : http://www.chavezthefilm.com/index_ex.htm
One of my coworkes will explain to you that such a project is impossible. He's an idiot.
A direct quote from your Wike:
Prevalence requires us to have enough RAM on our servers to contain all our business objects.
What do you do if you have a nice big data set that won't fit in memory? Businesses my company works with have millions of customers. Do they have to have all those gigabytes of data in memory to do anything?
Don't come at me with yet another memory resident thing that's supposed to be the greatest ever, when it doesn't come close to addressing the real needs of a database user.
I'm glad I'm not a subscriber right now cause if you payed to have the advertisements removed I don't think it would have caught this one.
--
WHO ATE MY BREAKFAST PANTS?
Big fucking deal. This is all in-memory querying from the same process. What about querying from another process or across a network from another machine?
Is anyone currently using this non-database solution in production?
Hell no! Are you stupid?
If so, has it sped development because of the lack of OO-to-RDBMS complexity?
No. Reduced complexity? Are you smoking Crack?
Was there a significant learning curve to speak of?
Is, not was, there a significant learning curve? Hell yea. Take everything you know and throw it all out. Then learn this new backwards system and in the end you have a worthless pile of crap.
It's no wonder that everyone is jumping on the bandwagon. NOT.
know that we of slashdot have voted
ye off the proverbial island, that ye
have been deemed rightly to have failed
in your quest for heterosexuality, and
have indeed been generally guilty of
faggotrous acts. Standing hereby, we
request that your ignorance of said software
be rightly punished by the general population
incarcerating you at the Grand National
Ancient American house for a period of no
less than thirty days, or the length of time
required for windows to be uninstalled from
your home computer and a fat black cock
shoved up into the roof of your mouth,
or something. Besides, pet project to you
probably involves a hamster wheel and a cucumber.
Too bad you already pulled that one off in
seventh grade science class. Except your teacher
was the cucumber.
You took the words right out of my mouth.
It must have been while you were kissing me.
-Meatloaf
If you could cache an entire MySQL database in RAM, I'm sure your MySQL performance would improve dramatically.
If you could then optimize MySQL's search routines for working on memory instead of disk blocks, your MySQL performance would improve even more dramatically. As it is now, MySQL must go through all sorts of contortions, probably using B-Tree-like structures for indexing, and other fanciful datatypes I can't even conceive of without a PhD. The reason for all of this silliness is the fact that MySQL's backing store is disk, not memory.
In a prevalence system like Prevayler, one of the fundamental tenents of the system is that ALL of your objects are ALWAYS in memory, and are only serialized to disk when they change, for persistence.
So...yes: as always, a memory-based system will be three orders of magnitude (or more!) faster than a disk-based system. Prevayler vs. DBMS is no exception to this rule.
But when your website has grown popular, your prevalance database has swelled to 30 gigs and you find yourself hosting it on massive systems with 12 gigs of core memory and another 30 gigs of swap space -- when your memory access times are starting to look like disk access times because of swapping -- well, don't come crying to mwe.
Prevalence is a brilliant solution, for small projects. But they only scale to the size of your physical memory, or slightly (50-100%) larger. You can't expect them to scale beyond that.
Correct link for the previous Slashdot article -- important, since it provides the lucid, straightforward explanation of what the hell this thing actually is that today's pointless-link-filled, cutesy bit of Astroturfing neglects to offer.
What I'm listening to now on Pandora...
I'm,
Not sure what the proper term for referring to the articles that appear on Slashdot should be but I can say that this article is about the worst I've ever seen in terms of promoting a pet project.
Slashdot needs to go one step further with it's moderating functionality.
Slashdot needs a way that crappy articles like this one can be moderated into the bit bucket and I don't have to see it anymore!
Caution: Contents under pressure
I'd be very interested in this, except for the single fact that's it's Java?
I may be offending some people here, but I hate Java. After having worked with it for a couple of years I hate it even more.
I've often had the need to store objects in other languages (Perl, PHP) and I'd have to say I've had a bit of difficulty mapping the data into an RDBMS, but not enough trouble to make me want to switch languages.
Actually, I don't have a huge problem with the Java language itself, just that it has to run in a VM, it's slow, takes ages to compile, has crappy string handling (compared to Perl/PHP but better than C)..
Yuck!
Anything is possible, except skiing through revolving doors.
Judged by existing work in this area, OO-->RDBMS is a very difficult problem to get right.
Solutions such as Castor and Hibernate have been used on something more than the sample databases that came with Access.
Also, why even call attention to your WIKI when it has so little useful information? Objections to Prevalyer - it probably won't work for my complex data because there isn't an indication that it has been used on real world problems.
I'm just going to assume their site uses Prevayler to store the page counter and revision information at the bottom of the linked page. Here's what I saw (times are Pacific):
[16:47] : This page has 10151 hits and 60 revisions
[16:50] : This page has 10156 hits and 60 revisions
[16:52]*: This page has 10170 hits and 60 revisions
[16:53] : This page has 10194 hits and 60 revisions
[16:54] : This page has 10220 hits and 60 revisions
[16:55] : This page has 10261 hits and 60 revisions
[16:56] : This page has 10311 hits and 60 revisions
[16:57] : This page has 10353 hits and 60 revisions
[16:58] : This page has 10413 hits and 60 revisions
[16:59] : This page has 10454 hits and 60 revisions
[17:00] : This page has 10503 hits and 60 revisions
[17:01] : This page has 10539 hits and 60 revisions
[17:02] : This page has 10578 hits and 60 revisions
[17:03] : This page has 10623 hits and 60 revisions
[17:04] : This page has 10666 hits and 60 revisions
[17:05] : This page has 10713 hits and 60 revisions
[17:06] : This page has 10748 hits and 60 revisions
[17:07] : This page has 10792 hits and 60 revisions
* - The Mysterious Future
Oh well. It did seemed to peek around 16:58, but I guess Slashdot users really didn't click on that link all that much. Too bad, that would have been fun ad-hoc to test.
A programmer is a machine for converting coffee into code.
I don't see why there's excitement over a bunch of Objects in RAM that are checkpointed to disk every once in awhile.
Here's another quote:
To avoid losing data, every night, or in any reasonable period, your system server saves a snapshot of all business objects to a file using plain object serialization.
I'm sorry, but if you sync every night, you're not even close to ACID compliant. ACID implies that when I say "Commit", it's commited to persistent store in such a way as to survive most hardware crashes (maybe not the computer room catching on fire, but certainly a disk head crash). That's the D in ACID, Durability.
I'm sorry, but you have yourself a nice little data access mechanism, not an ACID compliant database.
Eric
Geez, this just seems stupid. They want you to store all your data in RAM and save it to disk once a night via 'plain object serialization' If they really are using 'plain object serialization' in java then all data-access functions are going to lock, which means you won't be able to update anything during the serialization stage. And if you have a system crash, you lose all your data for the whole day.
If they had any sense then they would have everything saved to disk (like a journaled file system) and the 'serialize once a day' thing wouldn't be an issue.
And lets not forget the fact that object serialization is slow. I once tried to build a website using java collections and serialization, and it would take nearly half a second to save the whole sites data, with a 'database' of only a few thousand entries. I can't imagine long it would take to save the hundreds of megs of data autopr0n uses.
Maybe they've solved some of these problems, but it still sounds stupid. There are "real" OODBMs that let you keep your data in an OO system and let you keep that data on a hard drive, like a sane person.
autopr0n is like, down and stuff.
Please don't go around saying, "Could this be the end of RDBMSes?" That is just a crock of shit, and it really bugs the hell out of me. How stupid do you think we are to have a tagline like that?
Please watch "Bowling for Columbine" and it says that this type of exaggeration by the media, and most notably US media, is driving the Americans crazy paranoid with fear. It seems like the editors have fallen for the same thing, and it should stop now!
Let's have a modicum of dignity and avoid all the hyperbole, please. We are all somewhat tech-savvy, please treat us with the respect that we deserve!
I'm sure the technology is good, but for crying out loud, mainframes are still around 40 years later. RDBMSes are going nowhere for the next 20+years until true AI comes around.
Although MySQL is about 2.8 times faster for transaction processing, Prevayler retrieves 100 objects among one million 3251 TIMES FASTER than MySQL via JDBC, even when MySQL has all data cached in RAM!
Now many different people will interpret this statement differently. But, my interpretation is that under very specific circumstances it is 3000 times faster than MySQL. However, for transaction processing, which is the primary and most common role of a RDBMS, MySQL is 2.8 times faster than Prevayler.
Bottom line... For normal circumstances, MySQL is faster and many commercial SQL database servers are faster still.
I got all excited until i found out it was for Java only.
If they just benchmarked reads ... then the results don't tell much.
The Raven
...if I have the next day off. Might even be faster than MySQL to boot.
How does this compare to the established
leader in embedded DB ????
Apple WebObjects solves the supposed complicated OO to RDBMS problem quite eligantely. I've actually used it for a huge project and it worked quite well.
1st known failed CIA coup in South America : http://www.chavezthefilm.com/index_ex.htm
or you configured it wrong
or you were using Microsoft J++ 95 Alpha
or you had a bad IDE
or you're a bad coder
or you're stupid.
Or so the Trolldots will tell you.
Oh wait -- you're stupid by default, and you can pick another reason at random.
Flame completed.
This sounds a lot like the Zope ZODB. For those who are still stuck in the stone age, Zope is a python based application server that essentially uses object serialisation to store its data.
Imagine if every page in your website was an object- with methods, properties, Access Control, etc. You have different classes for different types of documents, and each document internally knows how to render itself. The ZODB is essentially one big persistant object orientated namespace- You dont have to parse your data into SQL and back again, it's always just there, elimenating a huge amount of work (and bugs!). Having worked with it for a year, I can certainly testify that it is leaps and bounds over relational databases for most things.
Wow, this is great news!
But what is a RDBMS?
SQLite is tiny, fast and ACID compliant. SQLite is a public domain embedded SQL database library. It is similar to BDB, but provides a complete SQL database.
read the FAQ
Does Prevalence Only Work In Java.
No.
You can use any language for which you are able to find or build a serialization mechanism...
I am NaN
It once struck me that one could hypothetically develop a language that is table based. Not a language that is table friendly but a language that is built on tables. Sort of like Lisp treats everything as a list this language would treat everything as tables and have a built in capability to evaluate and modify tables. Of course every table 'eval' would return another table that could be 'evaled' just like lists in lisp.
Maybe such a language is not practical for a variety of reasons but it certainly would suffer no impedance mismatch with an RDBMS. As a matter of fact its runt time would be an RDBMS.
Silly? Maybe. But I think everyone who's worked on enterprise OO application has this feeling that something between these two just doesn't click. Right now, for a java developer at least, the least painful option seems to be Hibernate. Great implementation even if the whole paradigm is flawed :)
Your pizza just the way you ought to have it.
No, really. RDBMS are many times more powerful. If you're doing something mickey-mouse, then fine, use prevayler. I won't stop you using it or ZODB.
Then, when $business wants to ACTUALLY DO SOMETHING USEFUL with the data that $oo-weenie didn't think of, you can pay $consultant to migrate it to an RDBMS anyway.
Personally, I'd much rather use an RDBMS->OO binding layer like (Un)CommonSQL anyway, even if I were programming in OO (and I'd only settle for CL-style OO, too).
Nice of you to mention Crystal Reports. I still am able to sell dBaseIII and ParadoxDOS programs, and I do quite well. They're great for implementing business rules.
I've never been able to make heads or tails of the Python content management systems. I read all that stuff Rueven Lerner publishes in Linux Journal, what the hell is he talking about?
I write programs to manage volunteers, clients, keep track of both inkind and dollar donations, MySQL and php work OK. I'll never figure out Zope and any of that other OO stuff. It's all Scientology to me.
I'm not sure about this, because I'm not exactly sure how the program works, but from what I understand, the main whoop about it is that it simply uses the ram as a hard drive to highly increase speeds. I saw some users on here talking about how it would end up being slow, especially for millions of users, where most of the data on those users would just sit in the ram and eat up space. Well, wouldn't any well designed operating system swap out the memory pages that haven't been accessed in ages? It sorta defeats the purpose of having it in ram, but at the same time, it works. Also, a well maintained database wouldn't keep records that were that old, but instead would store them to a more permanate solution such as a Tape Backup or a hard drive array.
Furthermore, ram is dirt cheap, and with the advent and steady rise of Flash RAM and mram (not sure if this is what it called, but it performs like dram, but like flash ram, won't lose data without being refreshed every so often by converting the electrical impulses into magnetics), but you should be able to fit enough of this ram into a machine (ie, look at the virginia cluster, cut it in half, and you should have about the power), back it up to a hard drive array every so often, and poof, there you have an enterprise solution. I really like this idea.. good work Klaus!
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I'm not about to give up PostgreSQL.
An RDBMS:
* Allows a wide variety of applications to operate on the data, in a wide variety of languages, at different times or simultaneously.
* Allows you to manipulate the data inside the database before you get it.
* Allows for a lot more storage, which is sometimes important when you need the memory for some other task.
What I like about an RDBMS (like postgres) is that my requirements constantly change. I try something for a while, then we have better ideas, but we need to work with our existing data. An RDBMS allows me a huge amount of flexibility with my data (also the reason I don't use MySQL...) and I've been able to drastically change the way my application works while still making use of the data that I have.
Maybe this is an OK database for some applications where you have the entire thing laid out in a perfect spec with no chance of a change. However, when I need to get at my data with another language, or it takes up more space than I thought, or I figure out that my application needs to change the way it works, I have no clue where to begin with a huge collection of "objects" that now happen to be obsolete. If I have relations, I have a solid representation of my data that an RDBMS can manipulate efficiently according to a fairly mature mathematical model. I'll take that over a collection of persistant objects any day.
That said, I think this has application in areas where you just need some persistent objects, and they need to be fast, and they don't take up much room. I don't encounter that very often, and when I do I usually just use postgres because it seems fast enough when the tables are cached. I suppose if the objects are really intricate this would be a nice system, because you wouldn't have to spend so much code on a mapping. It just seems so much more narrow as far as usefulness.
Social scientists are inspired by theories; scientists are humbled by facts.
I tried Prevayler and even loaded in 50k records from an old product table and object-ized them.
Yah, it was fast. Searches were great. I even figured out how to do complex object joins.
But I started having trouble when I tried to figure out how all the transactions worked. This was complicated by the wiki they're using, which was quite useless to me. It lead to many dead ends.
However, the real reason I found that I could not (possibly ever) use Prevayler is becuase it seemed the approach was for one machine and one machine only. There were no distributed mechanisms at all. Or at least, not how I'm used to working.
All the systems I've worked on in the past five years have all been with clusters of app servers. If all the objects on one machine were all in memory, then I couldn't think of an easy way to get them into the memory of the other machines. There was some talk about using Java Spaces, but that's kinda where I dropped off.
And the other issue was getting to the data from non app server machines. Like stuff to do back end reporting and things like that. I bascially figured out that for n-machine access, I needed something that, well, acted like a database.
I thought the idea was very interesting and maybe these things have been addressed. But when I really sat down with it for a few weeks, it just didn't pan out for me.
Of course it will suck if your project doesn't fall in those categories. Everyone can see that.
Sure, everyone except the person that posted it and the editor that let the story through. I'll admit I got sucked into reading more because of the overly generalized claims. "Bye RDBMS?" in the headline? Gimme a break. Prevayler is an incredibly specialized tool that won't be able to solve many real-world problems currently solved by an RDBMS.
Prevayler seems like a great idea. It doesn't need the deceptive hype. How about "Bye RDBMS for projects with fit-in-RAM databases?"
.. you swap !
theefer
"If there are so many after-the-fact solutions attempting to simplify relational database access and manipulation from OO, isn't it reasonable to think that there is something generally wrong with trying to cobble-together two disparate concepts with what are essentially high-caliber hacks?"
No. EOF and WebObjects solved this problem nicely years ago.
Are you trolling or are you actually dumb enough to believe what you just said?
You are aware, I assume, that hierarchical databases are an older concept than relational databases and were ditched as far as mainstream implementation went ages ago? You are aware, I assume, that these concepts are not new - just old technology that has long been dismissed as being useful in niche situations only that's being dusted off for no apparently good reason?
You're aware, I assume, that none of the DBMSs you mentioned are truly relational, and, if they were, they wouldn't suffer from the problems that are most commonly complained about?
You are aware, I assume, of the difference between SQL and "relational *"?
You are aware, I assume, that your comment was utterly ludicrous?
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
This might be nice for a certain class of applications, but unless that all (and more) works - and I can't see how it could - I wouldn't be too frightened if were Larry Ellison.
Programming can be fun again. Film at 11.
And I thought Quantum Computing was still part of the distant future...
A quick search on the wiki showed no hits for the word 'report'.
Note that the classic problem with object databases is that they focus on transactional queries, and that DSS or reporting queries are either too slow or too difficult to perform.
So, yeah it sounds nice if you want *both* an object database and a relational one. Not a bad solution if you already have a data warehouse on the side. But if you don't it just a lot of extra work.
Next...
Not having a SQL interface closes so many avenues... For a nifty (and remarkably solid) light-weight database, take a look at McKoi.
Max
Thomas Mahler of OJB has almost finished back-end support for prevayler.
So, in addition to many commercial and open source RDBMS's, OJB also supports this great OO platform.
cheers,
Matthew Baird
My proactive leadership must be working.
So if I understand you correctly you want software that will B2B edutainment portal internet enterprise mission-critical?
Yeah.
The buzzword-compliant expansion of "enterprise" is:"scalable enterprise PPP2P pan-galactic redundant XML warp drive," but it's "enterprise" for short.
"Despite fear, doubt, and memory concerns, it has reached 2.0 alpha."
Whew! I'm sure there's no problems with uncertainty, otherwise I would think the project is doomed.
Interestingly, I know developers can submit patches to solve "memory concerns," but what kind of work can they do to solve "fear" and "doubt" ???
When we haven't said hello to one yet?
I'm not sure how you can say your new technology is better than the old one when you haven't even bothered to check out a fully implemented version of the old one.
KFG
but I don't buy from companies who market unethically.
If you haven't got the guts to admit you're connected to a project you're pimping, you've lost any respect I might have had for the project.
Slashdot's token middle-aged housewife
Join the HFLU association today!
Learn some english, you sound like gap-toothed romanian trash.
And most importantly, was Cliff smoking something when he posted this, and if so, where can I get it?
What do you do if you have a nice big data set that won't fit in memory?
Don't use it. There is diferent software for diferent needs.
A dozen posts by you defending this braindead in-memory persistance scheme - why? Have fun developing your non-multiuser easily corrupted Prevalance-based systems.
Features
Transparent Persistence for native Java business objects.
3 to 4 Orders Of Magnitude Faster than databases via JDBC.
ACIDTransactions.
Zero Bugs.
could this be a world record?
...and better yet, it has "Zero bugs." Ummm....
Does anyone have any experience with Jasmine? [I think the marketing droids renamed it to some bland, drab, politically correct gobbledygook like "Advantage Integration Server" or some such nonsense.] We are thinking about giving it a test drive for our new database.
We would like to use it in a medical setting where we will be bringing in lots of multimedia samples [digitized video of surgeries, digitized electrocardiograms, digitized blood pressure readings, and the like], together with a handful of traditional ASCII parameters [name, rank, serial number], and Jasmine seems very intriguing.
Any anecdotes or insight would be most appreciated! Thanks!
There's a lot of information about distributed database integrity on the net. Take a look at it sometime when you pull your head from your ass.
"OO's rough courtship with Relational databases", I must be missing somthing.... Do people think that RDBMS is that complex? Or are these the same people using MS Access.
From the Wiki:
Prevalent Hypothesis:
That there is enough RAM to hold all business objects in your system.
IMO, this hypothesis doesn't hold water for 99% of business applications. Prevalent proposes that even if this hypothesis doesn't hold today, it might soon hold true because of breakthroughs in memory technology. But historically these types of ideas are flawed, as the real world has clearly shown that memory and disk needs will grow even faster than our ability to use those resources.
Sure I can take a 1998 application and run it with breakthrough performance by caching the whole application in memory. But I don't want a 1998 application, I want a 2003/2004 application. Do you think that the entire Slashdot comment database would fit into a couple of gigs of memory? How about the enite customer database for an average enterprise?
Frankly, if my database is so small that it fits into memory then I probably don't have performance as a primary concern anyway. Plus, do I really want to subject my entire database to constant mark and sweep garbage collection if performance is an issue?
--
.no sig
ogren
The object-oriented ideology as instantiated in C++ and Java is founded upon breaking data into objects, bearers of identity, which belong to classes, bearers of structure and behavior. (C++ and Java make little account of metaclasses, which are used in more dynamic object systems such as Python's class system and Common Lisp's CLOS. Templates are not metaclasses.) Objects have identity, so they can be equated; they are the unique bearers of attributes about themselves; and each object's structure is dictated by the class to which it belongs.
When object-oriented partisans look at a database, they see its relvars (or table headers) as bearers of structure and think of classes, and its tuples (or rows) as bearers of identity and think of objects. They see a database as a place to store objects persistently.
But this is not what an RDBMS does. An RDBMS isn't an object store; its relvars are not classes and its tuples are not objects. So what is an RDBMS? What is "relational" anyhow? Relational databases are founded upon relational mathematics, which is what you get when you cross set theory with predicate calculus.
Set theory is the branch of math that deals with collections of elements which behave according to formal axioms. Set theory lets you say, for instance, that if you have a non-null set R and a non-null set S, that you can construct a set R*S of all the possible pairs of elements from R and S.
Predicate calculus is the branch of logic that deals with quantified statements about entities. It lets you formalize logical arguments such as the syllogism: All men are mortal; Socrates is a man; therefore, Socrates is mortal. Predicate calculus deals with generalizations and instantiations of those generalizations.
What do we get by combining set theory and predicate calculus? We get a system that allows us to operate upon sets of tuples of values satisfying predicates. A relation holds tuples of values which make some predicate true. For instance, consider the predicate "Person x owes me y dollars." Tuples which satisfy this predicate will be pairs (x,y) for which the sentence is true. For instance, if Fred owes me 40 dollars, (Fred, 40) satisfies the predicate. It could thus be a tuple in the relation described by the predicate -- the one relating people's names to how much they owe me.
With the relational algebra (or an RDBMS) we can do operations upon this relation and others. We could, for instance, select a result set of all those people who owe me more than 50 dollars -- or join this result set with those people's addresses. Whatever result set we ask for will be calculated from the facts in the database. We might get back this result set:
(Barney, 75, 40 Elm Road)
(Megan, 60, 9 High Street)
Now, are the elements of this result set objects in the object-oriented sense? They are not. They do not have identity. The tuple about Barney is not Barney himself, or even a machine representation of him. It doesn't uniquely store attributes of Barney -- after all, we created it by joining tables which also contain such attributes. It is not even, truly, a fact about Barney exclusively -- for it is also a fact about the number 75, and about the address 40 Elm Road. It isn't an object; it's a tuple value, and values do not have identity as objects do.
Moreover, note that by joining, we can construct new relations from old ones. Thus, not only are tuples not objects, but relvars are not classes. After all, in OO we do not create new classes by joining, but by inheritance or encapsulation of old ones -- and creating a new class does not cause it to be instantiated into known-correct objects.
So what does this matter to OO people faced with RDBMS as a
What Not How
With C++ alocators you can create data structures right on the disk. You don't need to write your own persistence layer.
autopr0n is like, down and stuff.
Prevayler is not composed of matter or energy. It is unlike anything you've seen before.
What makes this pre-value-or any better than metakit, gigabase, dybase, mnesia, dbisam, sqlite, or any number of other pretty good data storage contrivances that also can make advantageous, expeditious and efficacious use of memory?
People always talk about seperating presentation from code, but isn't it a good idea to save your data seperate from your code? With a Relational Database, you have a nice sensible collection of data that's easy to understand in any programming language. This object stuff is complex and language dependant. Maybe code and data should stay seperate.
autopr0n is like, down and stuff.
1. download latest postgresql
2. fork it, changing only the name
3. build a beowulf cluster, with a couple TB of memory
4. run your database in RAM
5. ???
6. profit!!!
These folks are either very naive, or very silly.
They claim there's no need for two-phase commit (2pc), as though the only systems they need to interact with are (or will be) prevaylor.
Umm, hello. How about that 50TB database with all our transaction history? You gonna put that in your RAM-based database? No? Well, what happens when you need to do an insert into it, but commit only if the insert and the local transaction succeeds?
Hell, forget the 50TB database, what about the little Oracle database the guys down the hall use? Or the asynchronous queue that you post into?
It's a much bigger world than just your little project, guys, and you have to fit into it. 2PC is not an option. It's a requirement.
The whole "let's keep it in RAM" is cute, and for a lot of projects is probably all you need, but for any kind of large data set you just can't buy enough RAM to hold it all. Once it goes to disk, there's a whole new set of problems.
Also, the fact that you're responsible for defining and managing your transaction boundaries is really lame. It's not that hard to build check-in/check-out logic that can be used.
Come back when you have a real system that can handle real load with real datasets. Until then, I'll keep my RDBMS. You may have performance beat on the tiny systems, but who cares? THEY'RE TINY SYSTEMS!
DBAs are the most uncomprimising people in the software industry. They seem to think their databases are at the center of the universe and that we programmers need to bend over backwards to make their work easier.
It's the other way around. The business process comes first and the database has to be modelled around that. OOP is definitely one of the best ways to model software based on the real world processes and has withstood the scrutiny by DBAs. I agree that RDBs and OOP cannot get along in peace and I'm overjoyed now we have something on the horizon that may end the need for RDBs and the evil DBAs that promote them.
I will contribute heavily to this project and promote it after determining if it really does what it promises.
A little while ago, inspired by helpful members of the Prevayler mailing list I created a generic Prevayler system for object persistence in one of my current projects.
.. );
Basic objects implement a 'Persistent' interface and can also be 'Containers' which are simply Persistent objects that contain other Persistent objects. Basic CRUD operations can then be performed with a couple of simple Prevayler transactions. The system maintains the object graph hierarchy, aloowing you to perform transactions and queries using a 'path' that maps through the various containers. The code below shows the creation of a new persistent object (myItem) and Adds this to an object at the path 'item/subitem' (so there is a Container object located at 'item' which Contains a another Container called 'subitem' - myItem will be placed in the 'subitem' Container. The code then executes a 'select' , which will return the 'subitem' Container, which we can then use to access our newly created object if we so desired. We could also execute select("item/subitem/myItem.id") to access directly the object we just created.
Persistent myItem= new Persistent( id,.
AddPersistent addSub = new AddPersistent("item/subitem", myItem);
Container container = store.selectItem("item/subitem");
There is also a Prevayler Transaction to Update Persistent objects, using a similar path methodology. After we make changes to myItem, we can then use code like that below to execute the Update.
UpdatePersistent update = new UpdatePersistent("item/subitem/myItem.id", myItem);
Notes: the query language is obviously begging for XPath.
As the whole system is generic, it means that after a select you have to cast to the correct type, which can be a pain. For example, you may have a Customer object which implements Container. The Container returned from a select will have to be explicitly cast to Customer. I guess you could write a typed wrapper.
Generic typing also means that if you want a single Container to maintain more than one collection of Persistent or sub-Containers in a transactional manner, you may have to have the one actual Map behind the scenes, and have accessor methods that grab objects from this Map and cast to the correct type. I haven't quite worked this part out in much detail..
I think I will publish the source code after I have done some refactoring and come up with a robust Exception mechanism. Although I must admit that Exceptions often do my head in. It seems that a lot of the time if your system breaks, you are simply fucked and there is often not a lot that you can do other than get out as gracefully as you can.
http://www.info-architects.net/vapourized/
technoshamanic resistance within hyper-transgressive ontology
I will consider this 2.0 Alpha when Slashdot will be running off it.
Have a nice day.
Whatchu talkin 'bout fewl? All da programmars and dbaz been outsourced to Bangalore. All dere's left is just me tha janitor and dey got me pullin cables and hookin up routers and shit too.
Shheesh! Get with da timez already mon!
By that logic you might as well assume that we will all have huge amounts of NV-RAM soon, and if that's true, wtf is the point of Prevayler again?
If an app dies, its RAM will be reclaimed by the OS and erased. Backing up data to some other form of storage is useful even with non-volatile RAM for several reasons, one of them being the ability to take a backup off-site.
Will I retire or break 10K?
Python users may be interested in PyPerSyst, a project that began as a Prevayler port to Python, but is quickly turning into a very "Pythonic" OODBMS with a full-featured object management system on top of the core transaction manager, which is also improving rapidly. The PyPerSyst Sourceforge page and the PyPerSyst Wiki are where to go to get the skinny. As far as having the whole database in memory, there seem to be plenty of situations and application domains where it is very feasible to do so and is thus not a concern.
I don't mean to say anything against their product, which as far as I know is the greatest object persistence scheme ever hatched.
But they clearly don't know what a database actually is; they're confusing the issue with services that an RDBMS happens to perform as part of its job. It has always been possible to write procedural code that is faster than database queries because underneath a query is turned into a sequene of operations. When building a system to answer a single question, the system will always be faster without the database layer. Building a hash table or B-Tree to do a simple lookup simply can't be beat.
People have lost sight of history. Years ago, we used to keep our data in indexed files, and guess what? They were faster than databases of the day at doing the tasks they were designed to do.
However while databases are slower, in many cases much slower, than procedural code, they have an important property: they can be used to answer unanticipated questions acceptably quickly. How quickly is acceptably quickly? Well, if the database can come back with an answer faster than it takes a skilled programmer to come up with a special purpose program to answer the question, it has done its job. Compare this to their answer to the querying problem: write a java program. And that's a fine answer if having to answer an unanticipated question is a relatively rare event, which no doubt it is for many applications.
This gets to what a database is: it is a collection of information that that is organized to make reuse simple and efficient. This is different from business object re-use, which is about re-using logic; this is about re-using facts. Relational databases are unequaled at this task because they are based on sets and mathematical operations that are closed on these sets. This allows both the user, but more importantly the system's optimizer, to create sequences of operations that meet the user's requests.
These people may have a wonderful system for a lot of purposes, but they're really talking about a particular set of applications, for which their system might be better than storing object data in a database. Probably is, as far as I know. But really. No need for rollback because "transactions are instantaneous"? Well, they would be right if transactions really were instantaneous. HOwever, while their test case may be so fast they appear instantaneous, that's a long way from actually being instantaneous. In the real world bound by the laws of physics, transactions take finite time. Given enough objects to update, or high enough system load, or both, you will have to either (1) accept a possibility, albeit small, of inconsistent transactions being processed or (2) lock all the objects that might affected by a transaction, with attendent possibilties of deadlocking.
In short, I wish them luck; it sounds like they are producing some interesting and useful stuff. However, it isn't a database or a replacement for a database.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I really appreciate the idea of a RAM targeted object repository layer, but as often happens, the Java guys tend to present their solutions as panaceias to every single application domain that slightly ressembles the problems they are attacking. I am really curious about how Prevalence compares to more naive in-RAM data storage approaches. Despite raising attention to the large quantities of memory not used in high end servers (and to the project itself), I simply can't see the point to compare it with mysql.
Furthermore, I can't avoid noticing the curious culture that has emerged with Java that you always have a single application/application instance for each machine. The dedicated server concept came to give reliability and CPU power, but WTF, do I really need a dedicated server to every application I run?
Though prevalence the concept works in any language that supports Serializable, the Prevayler(tm) brand implementation is for the Java(tm) platform.
Will I retire or break 10K?
I don't see how these are incompatible, particularly with languages with introspection, as someone else mentioned. Using a template based class generator that generates my classes from my database, and reflection in C#, I have a pretty seemless way of moving my classes to and from the database. And the really cool thing is I don't have to keep ALL THOSE OBJECTS IN MEMORY!
Y'all may want to take a look at for some better (even better than the Prevayler website) information on the problem space that Prevayler is good for.
It seems to me (in agreement with every commentor who has mentioned that this parent (Slashdot) article's title is misleading and inappropriate) that Prevayler's strength is in making it easy to persist *business objects*, not do away with the RDBMS entirely. If you've a strategy that involves tabular data as well as objects, and doesn't absolutely require a closer-than-reference coupling of the two, then Prevayler might help you out. Particularly if the business objects mutate very often during runtime.
I can envision, for example, raw data stuck in normalized tables in an RDBMS, with the *roll-ups* stored in Prevayler objects persisted elsewise.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
Nutz. Slash ate the link because I am a moron. The link is: [http://www-106.ibm.com/developerworks/library/wa- objprev/]; referenced by the original Slashdot article.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
Having just started on a struts/ibatis project in which a relational database is used to populate objects, your explanation really provided me with some great theoretical background.
I wish that I had the power to mod you up to a 6.
- JML
thats all
(2,3-Benzopyrrole)
Sounds like one big race condition waiting to happen to me. Even with the entire data base in RAM, transactions take time. If the number of transactions goes high enough, sooner or later a race condition will apply.
the prevayler FAQ took me to goatse.cx. I'm not joking; i wish i was however. http://www.prevayler.org/wiki.jsp?topic=SystemPrev alence
some kiddie modded the website so it goes to goatxx.cx
I don't know about anyone else, but when I clicked on the link to:
g Po ints
http://www.prevayler.org/wiki.jsp?topic=Startin
I got the disgusting goatse.cx website. Is this a case of hijacking a website, or is Prevayler a hoax?
I know websites can be stolen from others, thus we have the term "cyber squatters", is this a case of that?
I have been doing OOP for over a decade, but then I stumbled on Open for Business (http://www.ofbiz.org) which has an entity engine that basically throws out the OO model all together. At first I was offended, but as I thought about it, it makes sense - a bean class for each table just bloats things. Instead, OFBiz's entity engine handles the persistence and the service and event modules handle the business logic.
nio allows memory mapped files and shared memory with native applications so anything can be written in Java. In proof there are other DB's in Java that don't take that approach.
The "Prevayler Team" has written a persistent HashMap with a redo log, using the command pattern. This is exceptionally trivial and is in no way comparable to a database. A database has things like: 4GL query language, referential integrity constraints, data integrity, queryable metadata, separation of logical and physical layers, data independence, declarative rather than imperative querying, dynamically assembled queries, and gazillions of other things. These are the real features that we mean when we say "database." These features are absolutely necessary. Prevayler includes none of them. It is an extremely trivial persistent HashMap, that's all.
Thus, when the prevayler team says "throw away your database," I must assume one of two things. 1) They're trolling for publicity by saying outrageous and purposefully stupid things. Or 2) They are shockingly, mind-numbingly naive, and they don't know what a database is or what it does.
The author of Prevayler wrote this about himself: "Carlos Eduardo Villela is a 19-year old Brazilian graduate in Information Systems... almost 8 years experience has made him a Java and Python enthusiast."
Thus, I have to assume that the authors are mind-numbingly naive. Don't get me wrong, I'm sure the authors are very bright, and I know that some good insights that went into the implementation of prevayler. But let's not throw away our databases quite yet.
I find just about anything to be a better solution than MySQL....
A good object oriented database, like GemStone (for Java or Smalltalk) allows the objects to remain "alive" while in storage.
I have concluded that what OO affectionados really want is the concept of bubble memory. Bubble memory was being heavily researched in the late 80's and promised to create a kind of RAM that would keep memory even when the power was turned off. You only needed power to change state, not keep state.
This is more or less what Prevayler-like tools seem to do: give one the illusion of bubble memory.
Sure, we would all like bubble memory, but it seems that OO needs it more because it depends on behavior as the primary communications conduit between system/application parts, whereas relational approaches use data and meta-data for such communication. It is easier to recreate data messaging between boot cycles than behavior.
I don't know what happened to bubble memory. It never seemed to take off like promised.
Table-ized A.I.
The somewhat naive authors of prevayler confidently announce the following on their website:
"No one has yet found a bug in Prevayler in a Production release. Who will be the first? [bold in original text]."
I already found a serious bug in the current production release. From the prevayler source:
ObjectOutputStream oos = logStream();
try {
oos.writeObject(command);
oos.reset();
oos.flush();
} catch (IOException iox) {
ObjectOutputStream does not guarantee atomicity. If your command object is larger than the page size of your disk, the "transaction" will take at least two page writes. A software failure between those page writes will lead to "half a transaction" being committed and a subsequent corruption of data. Once data integrity is lost, it is often difficult or impossible to recover. Prevayler has nothing to handle this case. Thus, prevayler does not correctly implement ACID, because it doesn't guarantee atomicity (half a transaction can be committed), consistency (referential integrity would be destroyed in such a case), isolation (this failure wouldn't be isolated to a single transaction) or durability (the problem would only show up upon reloading).
Finding this bug took very little searching. I am apparently the first person ever to find a bug in prevayler. Do I get a prize?
The tool is cool at first sight.
When the object model needs to be revamped (add new fields, references etc), the whole "big file" becomes irrelevant as the serialized objects are not compatible with the new definitions...
After using it for a simple product of mine, I went back to RDMBs that knows what a technology-independent representation is (and real things, supported by vendors, not mySQL crap).
Can anyone explain to me how on earth it is ACID compliant from the user's viewpoint?
I think the real solution to the DB/OOP problem is somthing like this.
That is - modify the object system itself to support transparent database access. Doing this, you'll be able to write the rest of the application pretty much without worrying about the database backend.
-K
--
Simon
If it's so good why are they using the dumb filesystem to persist their own wiki?
I concur. Eating your significant other's feces is very exciting and can bring you deep into a submissive state. You might want to introduce the subject of a FemDom relationship to your wife. I did this with my girlfriend and life has never been better. I've signed the slave contract with her and now she owns everything including me. Brown showers happen once a week and golden showers are nightly. There is nothing more satisfying than my girlfriend's sweet golden nectar in my mouth and on my face. For more info on the whole FemDom relationship angle of brown showers, visit this site. Elise Sutton discusses the topic quite nicely and allows for lots of approaches. This is the way that the world is shaping up. Women are more in charge every passing year and their superiority over men will eventually be the mainstream way. I can't tell you how much more sexual pleasure I get from orgasm denial and cuckolding. My girlfriend hasn't had sex with me in two months, but she fucks her new lover every week. Sometimes I am present, and other times she locks me in my cage in the basement leaving only an intercom on so that I can hear her moan with pleasure as she gets fucked. I know a lot of this probably sounds odd to most folks here, but this really is an awesome way of life. Check it out and comment folks!
I posted a news item some days ago about oddb.org (see also linuxmednews.org). The complete 'datastructure' of oddb.org is done with Madlaine - a prevayler solution as mnemonic. Yes it has sped up development, yes the search queries are delivered faster, yes we are very happy with this new technology. You can have a look at our source at download.ywesee.com/ruby/oddb.org. You can test online at http://www.oddb.org. We are using Madlaine also on other mission-critical projects and it also works great there.
So this is an OODBMS that doesn't allow me to query, that holds all objects in in memory.
Right.
And how is this different to just storing my objects in memory? In some kind of data structure, like I usually do? Ok, then it serializes them. This functionality is pointless.
If I need lots of data to be persistent I want to use Oracle, SQL Server, SapDB, and maybe even MySQL so that other applications can see the data.
Otherwise, then I can just hold it in memory. If I'm just holding it in memory, I don't need another product to do it.
The camels are coming. I'm in love.
I wonder what happens when you update your Java classes, and try to load the old serialized data from disk... incompatable serial ID version errors? All data lost?
One could easily claim that while programming today is all OO, data storage is still left in the procedural era (in fact, there's indeed too much OO-Relational mapping to back this up).
The biggest problem is of course to make an understandable and flexible solution. To be honest, at first sight, I don't understand sh*t of Prevayler, while other so-called OODB's I "know", never seemed to care much about (more or less) language-independent mapping; they just stored serialized objects. A product of my own just mapped some basic datatypes to an RDBMS (which works, BTW, just fine for data objects).
I would welcome someone who would be able to answer these in only a few words:
- Does Pv only store data objects, or also other program runtime objects (like with Smalltalk)?
- Do they attempt language-independent storage?
- Is the storage structure searchable/ readable?
Thanks.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Ok, I'll bite. I don't get it.
I've developed several medium-sized projects using OO languages interfacing with a RDBMS. One used MSSQL, one used Oracle, and a couple used MySQL. (Just to be a bit more precise, by medium-sized I mean a few tens of thousand lines of code and up to 50 concurrent users per location to which the application is deployed.) I've never seen a "rough courtship with Relational database" or a problem with "OO-to-RDBMS complexity" and I would not call developing OO applications that interface with SQL databases "tedious".
Secondly, the incompatibilities can easily be addressed by creating a database connection class. The SQL implementation aren't so different that you can't pass the implementation name (i.e. MSSQL, ORA, MYSQL, etc.) to the constructor or add some #ifdefs (or the equivalent) in appropriate places and pass the right implementation-specific SQL based on that. If you do it well enough, you can reuse this class across projects. At least SQL is somewhat standardized (haha, I know). By using Prevayler (which sounds like it's some 12 year old AOLer's screen name, btw), you're locked in to one vendor. What if, for example, I have a client who can't/won't run this software? There are enough SQL variants to make pretty much anyone happy with the platform.
The poster talks about a lot of high-caliber hacks... if a developer understands the purpose of an RDBMS was supposed to do, they wouldn't need to resort to "hacks" (I was expecting an example or some useful supporting information from the poster's link... unfortunately, I was sadly mistaken). An RDBMS is a way of storing and retrieving data. The implementation of the RDBMS should have no impact on the design of a program. If it makes an OO-zealot feel warm and fuzzy, they can just think of the entire RDBMS as a giant object sitting off in never-ever land with connect and query methods (at the most basic level at least).
Lastly, I see a lot of hot air on the Prevayler website. Things talking about freedom from query languages, support of any algorith, etc. They don't seem to have a lot of information on these statement. They don't say exactly how data is stored. They seem to claim that Prevayler will organize your data in the most optimal fashion since they seem to think DBAs are evil people who, for no reason whatsoever, come up with wicked database designs intended to make developers miserable. They don't say exactly how they store data. These kind of omissions scare me. I don't trust projects just because theyre open source. (Note: If this information is available, it wasn't obvious. Even if these guys are the most awesome OO developers ever, they suck at presenting information).
What is the big deal here? Seriously... I'm just not seeing the problem.
I'm sorry if something like this has been posted before but I really didn't see anything covering these questions. Also, if it sounds like I'm a bit mean in this post, it's because as I was writing the post, I tried to answer my own questions through the Prevayler website but was unable to find any useful information -- in fact, I ended up with more unanswered questions than I started with. In short, zealotry combined with lack of information makes me an unhappy camper.
Finally a non-scientific application that will actually make use of the totally insane and useless amounts of mem their x86-64 thing lets you address.
The idea of Prevayler is good, but it lacks a few things:
* How about really large databases? I know people who administer databases of 300 GB. There is no way you get that much RAM in a machine. Besides, I wonder how long the nightly snapshot would take.
* How do you implement clustering, where different machines access the same data. This could be implemented using synchronisation protocols, but that would reduce the speed dramatically.
Why not use the in between solution, like ORDBMS. PostgreSQL has a very fine implementation if this.
eg. A Person { } and a User { extends Person}.
I just started using Directories again and I don't know that much about it's internals. Isn't OpenLDAP based on the BerkeleyDB libs and isn't LDAP somewhat object-oriented?
drawback for LDAP is that write calls are not very fast. A directory is better for few writes and many reads).
F/OSS & IT Consultant
In 1992, we were supporting a large COBOL application that was trying to run on an undersized mini (some kind of nasty French system, a BULL/TDS) that tried to immitate an IBM mainframe but with pathetically little memory.
The RDBMS was Oracle, which ran reasonably well because it had its own CPU, and about five times more RAM than the main system.
But the applications had lots of problems getting their data into memory.
So, we made a memory-to-disk serialization system, in COBOL with a few assembler subroutines. It was quite fun: swapping large amounts of data into large sequential files addressed by record number. It was also incredibly robust, mainly because it was so simple.
It was also at least 3000 times faster than the Oracle database, and I'd reckon (since we never tested this) probably around 50,000 to 100,000 times faster. That's easy when you are basically acting as a memory swap system: 95% of your accesses are from live memory.
But... but... this is _not_ a database product and it is an unfair and unwise comparison.
A database holds long-term persistent data and (most vitally) makes this available to multiple readers and writers through various non-trivial locking mechanisms. Additionally, a relational database provides non-trivial mechanisms for indexing and searching and linking this data together.
Lastly, and so very, very importantly, a database is independent from the application programming language. I am 100% sure I could read that same Oracle database today, in C, PHP, Perl, Java, or even COBOL if I could find a compiler.
Separating the database from your application implementation is such a fundamental design principle for serious application development (along with separation of the UI) that this concept, however fast and neat, is something I'd reject out of hand for anything our company made.
Ceci n'est pas une signature
Call me a troll, but I have a huge problem with the problems associated with OO's rough courtship with Relational databases comment. I've worked with OO and RDBMS professionally for the last 12 years, and have never had problems with a rough courtship. Anyone care to elaborate?
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
Oh come on. You're making the same mistake as 90% of the Slashdotters: you judge something without even having looked at it.
Prevayler 1.0 contains something like 8 classes with 400 lines of code. That's a dimension where it's still possible to code without errors if you are really really careful and test a lot. That's one of the main ideas behind Prevayler: Get rid of the enormous complexity of a full-blown database system.
Most of the complaints about Prevayler are nonsense. It is neither vaporware, an "amateur" project (whatever that is) nor unreliable or unusable.
I can tell, I have written a large web application with Prevayler, and it has been serving thousands of users 24/7 for more than a yer now.
Prevayler does have its own share of problems of course. In particular, there are three that actually hurt:
-There is no direct way to browse or manipulate the database. Everything must be done through Java code that is part of the application itself. You can also see this as an advantage though: Think about data integrity.
-Schema evolution is a pain. Since Prevayler relies on standard Java serialization, you have to live with Java's schema evolution mechanisms. Which really suck.
-Java lacks meta-programming facilities, so you end up writing the same code over and over again for simple things like a table with 10 different string fields (getter/setter methods etc). On the other hand, the complex parts that usually force you to write near-unreadable, slow SQL statements tend to become very easy and efficient.
Regards,
-Stefan Reich (www.drjava.de)
Wrong about MySql failing to gracefully scale to RAM storage, btw:
MySql polymorphically implements several different types of table, all conforming to the same interface. One of those implementations (HEAP tables) is designed to store data entirely in memory:
I have been talking about this a long time now. Unfortunately, no one listens. Never mind, I will keep repeating it for as long as it takes for people to understand:
We need to ditch our RDBMS/filesystems whatever. We need to replace all those with the Hierarchical Object File System. The system must store information into objects, and each object could be a container of other objects. Objects would be persistent. Each object should be managed by code handled automatically by the operating system, loaded on demand, and run either in the same process, different process or remote site. Its state would be automatically handled by the O/S, ala Prevayler. The programming language to back up this mechanism would be component/object-oriented and would run either statically compiled, dynamically compiled or interpreted as a script.
The Prevayler system is getting close to it, especially regarding the persistence mechanism. The next step is to apply it all over the O/S. Remember, that we humans use information, not binary data.
If you're tempted by the RAM-based performance of this, but you don't want to give up on all the good things a RDBMS offers, check out MySQL HEAP tables - they are a polymorphous implementation of MySql's tables that are designed to be stored in memory.
From the site:
"Rollback Is Needless"
What if an error occurs and the program needs to revert to a sane, consistent state? This is why I need rollbacks, not for contention resolution.
All I can say is "EWWWWWWW!!!!"
Un-news
http://bbooprevalence.sourceforge.net/ I have been playing around with this one for a while now. It definatly holds promise with certain types of applications. Recently the sites we (company) have been building do not allow for such an architecture and we really needed to SQL Server. Otherwise, I wait for the day to use this in an architecture. It is blindingly fast and pretty easy to code against. If the XPATH queries ever work fully this would be amazing product.
Better shut up or port anonymously next time you write such nonsense
I would tend to agree that the website oversells Prevayler, but it does get your attention. I used Prevayler in a project for work where we wanted to distribute a decision support system using Java Web Start. The system downloads data from a central server and works with it offline, producing reports and charts. It is meant for laptop users who will not always be connected to a network.
Without Prevayler we would have had to install a DBMS on each client machine. With Prevayler we were able to avoid that and create a fully cross-platform system in 100% Java, entirely deployed through Java Web Start.
Since this project we have used Prevayler on other systems where the amount of data involved did not justify buying an Oracle license. We have even used it on the server in a few cases.
Prevayler will never replace Oracle here or anywhere else, but it IS useful and well worth checking out.
Save your time. I wasted two hours on their site w/o finding any serious answer to how they allow simultaneous processes to write to shared information (without lost-update-types of problems), so that's probably all one needs to know about Prevayler. They may have something good to use in certain situations but any project "documented" with over-the-top hype substituting for data and serious info is not being run in a trustworthy fashion.
"Be thankful you are not my student. You would not get a high grade for such a design
I evaluated prevaylor a few weeks back, to see if it was a fit for a current project. It was not. But as soon as I find a project for which it fits, I will definitely give it a go.
.NET version, which is the one I would be using.
As I see it, prevaylor is good for:
* small single pc system, or web based system
* no need for external queries
* system that stays static once developed (because it is very hard to evolve a prevaylor system).
It would also be great for prototyping, because that usually meets all 3 criteria.
Incidentally, there is a
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain
Every once in a while, a post of this nature appears on Slashdot. I haven't like at the Prevayler project recently, but as I understand it, it is more of a supped up object streamer than a database. These projects and the ideas that drive them are fueled by college students who overdosed on OO theory in college and try to fit information into their carefully defined view. XML has similar issues. OO streaming and XML have real applications, but IMO are absolutely no threat to 'Relational' Databases in the business world. While OO is a useful and interesting branch of programming, its application is orthogonal to database principles and information storage. True and correct information storage is based on logic, not on efficient language bindings. Since stored data is really just information, or more technically, a sum of all constraints, it can describe anything, including 'objects'.
.net platform, I can use the built in serializers to stream objects to XML with very little programming. With some XSLT and some more programming, a general approach could be used with some features (i.e. querying) of a crude DBMS. While the performance can be stellar for writing and reading (Microsoft's XML serializer can a achieve 10 mb/sec output on cheap hardware), concurrency is a nightmare and scalability is worse. While this seems attractive to OO programmers who are put off by brokering objects in and out of a non OO storage, any type of useful data mining with this approach is realistically impossible. Even with infinite computer resources, the weakly defined logical model of serialized objects contrasts unfavorably to the SQL model (and SQL contrasts unfavorably to the relational model, but I'm nitpicking!).
This is nothing new. In Microsoft's
Imagine database objects serialized to XML and stored in Postgres as blob objects (but without mvcc and atomicity) and you have something similar to Prevayler. Obviously, since you cant make a useful index out of a blob object, ad hoc queries are impossible unless you introduce a 'meta parsing' stage for indexing, relating (such as it is) and performance optimization -- now destroying the 'generalness' of the storage. In SQL, all you have to do is type in 'create index', what sane db administrator wants to give that up?
Generally, Postgres is more suitable in business environment in almost every way, but the common misunderstandings about databases (urban myths?) in the IT industry are so widespread that newcomers to the field must have terrible trouble getting correct information.
Regards,
Merlin
I'm sure the technology is good, but for crying out loud, mainframes are still around 40 years later. RDBMSes are going nowhere for the next 20+years until true AI comes around.
Think of it this way, we still use files to store data and there are lots of low level file operations we can perform, but RDBMS encapsulates all that so we can say "create table" and "select * from table" and not have to muck around with accessing the files ourselves, just get the data.
In the same way, what this project should do is automatically USE an RDBMS on the backend to store all those transactions and retrieve updates. If there was some option to keep all objects constantly up to date with the database I would love it. No translating from objects to DB because it would all be done for me. No click here to save, because it would be done as things change.
I'm sure that's what future libraries will do for you. I think this would be a great application if we already had that new magnetic memory that is supposed to replace hard drives, but for right now, if I have a power failure I don't want to suddenly lose my whole database.
I wonder how this project would compare with a MySQL hash table.
Thank you for a working example! I hadn't thought anyone would actually bother answering the article poster's questions. I'll check out the links.
We use prevayler and it's pretty good, but you still have to distort your Java code to accommodate the Command pattern to use it. I think the real solution is a well-designed new O-O programming language that provides fully transparent persistence via some kind of underlying object-relational db implementation.
Where are we going and why are we in a handbasket?
If you were starting fresh without disparate legacy applications, you would use this in a cluster and simply add functionality to it based on departmental needs. That way, everyone shares the data (which is exactly as fast as your CPU and RAM will allow without the Hard Drive lag). The more memory and cpu utilization you need, the more cheap Linux workstations you throw at the cluster.
What you end up getting is an inexpensive supercomputer that can also load other applications not associated with the data in the original application.
Or, as the author of the project has posted in his wiki, there's no reason why your objects can't feed other applications, or other applications be treated as input for your objects. Afterall, no application is an island. Input/output is required, it's simply up to you where it comes from and where it goes or copies to.
From my weblog:
Could loading all your objects into memory, and keeping them there, possibly work? That's what the folks at www.prevayler.org think. Breakthroughs in memory technology, cheaper RAM, 64-bit computing, better JVMs -- all these instances of technological progress, we are told, ought to finally make it possible to keep all your domain objects in main memory. The advantages are obvious. Systems become simpler. The need for caches is all but eliminated. Performance can be enhanced dramatically as there is no longer need for expensive disk access or network communication with the database. No longer are you limited by the query language of your database; use whatever query mechanism that best suits your needs.
Wonderful! But, does it work in practice?
1. Cheaper RAM. While it is true that RAM has been getting cheaper and cheaper, the same is true of hard disks. A look at the web site of a nearby computer shop reveals that a 512MB RAM unit costs 84 euros; you can buy an 80GB hard disk suffering the same amount of monetary drain. It is not to be expected that this two-orders-of-magnitude difference would disappear anytime soon. Therefore, for large amounts of data, even if you could buy enough RAM, would you really like to?
2. 64-bit computing and JVM support. Extensions like Intel Extended Server Memory Architecture aside, 32-bit computers can address only 4 gigabytes of data. In practice the number for an individual application is less, and for a Java application even more so. Java heaps on x86 platforms were restricted to approximately 1.5GB last I looked. This is not enough for many enterprise applications. It is not nice to be running at 1GB heap utilization, knowing that users are creating new objects all the time, fast...
64-bit architectures get rid of the 4GB barrier thus carrying with them a promise of prevalence nirvana. Right now, though, all 64-bit systems are stratospherically expensive. Have you seen the prices of those Itanium 2 boxes? AMD promises to come to the rescue with x86-64, but the practical utilization of this architecture from Intel's chief rival in Java application is a little off, since there's not even a Java VM for x86-64 yet (though one has been promised to appear in 2004).
3. Simplicity. I'd love getting rid of caches. Caches suck! And don't even get started on all that pesky O/R mapping stuff. Without a query language, though, the distinct possibility exists that the magic box full of promises will turn out to be half-empty. Writing queries in SQL is, well, convenient. If you have to manually construct hashtable-based indexes, then the value proposition of object prevalence diminishes. Fortunately, there are object query languages, though none of them seems to be widely accepted as a standard. However, there should be no obstacle in principle why such standardization couldn't take place.
4. Performance. Queries from a hashtable-based index are fast. For updates the situation is different, as updates will have to be written to the command log; all in-memory indexes, too, will have to be updated. If such indices are not maintained, databases could in case of a huge data set turn out to be faster, even though they often have to access the disk to get to the data. The big performance advantage that I see coming from object prevalence is in the area of very complex, deeply-linked data structures: you can build them and still not worry, given the right combination of hashtables.
Conclusion? If an application deals with lots of data, or if the amount of data grows fast or unpredictably, object prevalence won't be viable until 64-bit architectures establish themselves in the marketplace (which should take a couple more years). Regardless, you can look for subsets of data that could be kept in memory in their entirety. The more often that data is accessed, the more performance benefits will accumulate. For example, in a server-side business application, it might be possible to
Here is an interesting Q and A I ran into about Revalence
http://www.advogato.org/article/398.html
The versions of Prevayler that I have made myself familiar with require that all data stored must reside in memory. I suppose that the data could be clumped into non-interacting sets, and those pulled in separately, but... well... I find the limitations unacceptable.
That said, I was not able to determine whether or not this limitation still applied to the new version. The basic idea is excellent, but implementation is the key.
(P.S.: If it's in Java, I wonder if it compiles with gcj. If so, then it may be quite useful to those with small enough databases, or even, assuming that they have fixed the all-or-none problem, to people with large databases.)
I think we've pushed this "anyone can grow up to be president" thing too far.
-1, Subject Troll
The problen space for prevayler happens to match several projects I am working on. They have the properties of a small database, single instance use, and load-all-and-flush-once-in-a-while. This matches pretty well most small web applications. If you look at .NET and C# the approach there is to load the entire database into memory, and flush the changes. This was chosen by the Evil Empire because it meets a certain need and class of web site application.
I think that the rhetoric on the prevayler web site is a bit extreme, and may not be in the best interest of the project. The comments on slashdot are much more extreme, and rather insulting and poorly thought out.
I, for one, am glad that Slashdot carried the article, and am thankfull for the team that wrote prevayler for making it open source. It is a good solution for a certain type of application.
Prevayler is a horrible solution for some other types of applications where an RDBMS is appropriate. If you need the advanced capabilities of SQL than by no means should you use Prevayler.
Once 64 bit Java VMs become common, then Prevayler will become appropriate for a broader class of application. Even then there will be some applications that need the features of a RDBMS. Maybe at that time Prevayler will gain more features that RDBMS's have, and probably be wrecked by code bloat. Lets just hope that Prevayler keeps it's simplicity and keeps targeting the application space it was intended for and does not try to compete with RDBMS.
So, why all the harsh comments? Perhaps the people making the harsh comments simply never created anything usefull in their lives, and are attempting to agrandise them selves at the expense of others. My advice to them? "Get tharapy". Or better yet, the best tharapy would be to actualy work on an open source project and see just how difficult it is.
Inside every complex program is a simple solution trying to get out.
The web site is breathtaking in how it compares apples and oranges and then draws conclusions from that. I spent a lot of time in the OODBMS world and we could always come up with a benchmark that was arbitrarily faster than an RDBMS and there were many applications where this was proved out. But we would never say that OODBMS was going to replace RDBMS because we knew that there were plenty of applications where RDBMS would kick OODBMS butt. What these people seem to miss is that you need to use the right tool for the right task - some things work quite well is in-memory databases and some things suck wind big time; the same applies for all other database technologies.
Dr. Rick
- "It's such a fine line between clever and stupid" (Nigel Tufnel)
- Zort! (Pinky)
Why should I switch models of data storage to match a dying architectural style? The future is in SOA. Forget about this day-late-and-a-dollar-short product.
"With Prevalence we are finally free to create true object servers and use objects the way they were intended all along.
We are able to use any algorithm, data-structure and query language we please. We are no longer constrained to the ones provided by database and application servers which must run on disk data-blocks.
We believe the whole OO community is finally free to recover from the atrophy caused by database and application server restraints. We no longer have to distort and maim our object models to satisfy their limitations.
We no longer have DBAs imposing us database layout restrictions. We have freed them to do something more useful.
We have set fire to the table-models on our walls. We have deleted our database creation scripts. We no longer have to keep them updated.
We no longer have to license, install, configure and maintain a database and application server every single time we want to develop, demonstrate or deploy our systems for any of our clients. Give us a Java VM and we are good to go." -- http://www.prevayler.org/
All you need to add is "Now let us partake the mystical kool-aid, and we shall welcome our new Object-Orientated Overlords.", and you've got an official Jim Jones' approved cult with tax-exemption and fashionable robes.
I'm sure Heaven's Gate had similar phrases to win converts.
"There is no spoon." - The Matrix
Let us not forget about DBD::SQLite [cpan.org] — a DBI [cpan.org] (Perl [perl.org] Database Interface) driver which, not being a driver per se, includes a *full* SQLite distribution, so when one needs to use SQLite in a Perl program, one is only perl -W -MCPAN '-einstall"DBD::SQLite"' away from $dbh=DBI->connect(q(dbi:SQLite:dbname=dbfile)); which is truely amazing.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."