How about JISP? -- TieyingLiu
I do not think JISP is in the same category as Prevayler
- it is 'poor man' disk-based
BTree and/or Hash storage with no transaction/concurrency features. It could be
ideal for read-only/CDROM databases, though. Still, it is closer to RDBMS
than to Prevayler
Say there is a Person object that has a field to hold an Office object.
There is a collection of Person objects. There is also a collection Office objects.
The collection of Person can be queried to answer something like:
Persons with lastName < "n" are associated with what Offices
But, can the Office collection be queried to answer something like:
Offices with roomNumber < 200 are associated with what Persons
A "relation" like this in a database can be queried starting from either Person or Office entity. But, is this possible in OO (Java) to get a reverse lookup (e.g., to know which Person objects reference any particular Office object)?
looks great! Trying to adjust from RDBMS
thinking. Responses appreciated!
I think you're inverting the ideas. How does a person, in the real world, hold an office? I think that the office is the one that holds one or more people. By straightening out your mapping of the real world to objects, things get easier.
If an Office has 1..* Person, and each Person belongs to an Office, things get a lot easier to query on @:)
Well that's just stupid. I know around here that offices have more than just one person in them. And all valid query ideas should be supported. This is where SQL rocks.
And why does everyone think mapping tables to objects is impossible?
[I don't. I just think its a pain. --KlausWuestefeld
If object A has relation to B, then in any case, you simply associate a column entry in the table for A with the corresponding rowid for the Instance of B in the table that stores B. ( Heck with suitable column support, one could store even the source code for a given method, even the bytecodes... ).
Objects and relational databases can have perfect 1 to 1 mappings, and it's very very easy to define all sorts of arbitrary queries. Sure, they might not be useful now, but who knows in the future?
Given a table of employees, and a table of offices, it's very easy to find those employees who don't have offices, and those offices who don't have employees ( Maybe closed branches, or leftover cruft or unpurged DB entries, a useful query )
How can I do this in a consistent manner in Prevayler
It's a no-brainer than in-memory access is fast. Serializing snapshots has been done before. Unless I can write useful, potentially arbitrary queries, why bother?
To Daniel: Well said! That's the point. Relational Database are about storing data in a normal form *while allowing all possible queries*. They also standardize the query syntax and semantics.
All: Show me an SQL interface running on the top of Prevayler
, then we will talk. If what I wanted was objects in memory, then why would I need a database? If you compare your performance to that of a database, then please compare with the features of a database as well. Before relational databases we had hierarchical systems. There is a reason why nobody uses these anymore. Having a hierarchical data model in RAM and comparing the access speed with Oracle
on simple table lookups is ridiculous.
Given a table of employees, and a table of offices, it's very easy to find those employees who don't have offices, and those offices who don't have employees (Maybe closed branches, or leftover cruft or unpurged DB entries, a useful query). How can I do this in a consistent manner in Prevayler?
Trivial. But how about a query over polimorphically evaluated methods based on the current millisecond? Can your database even handle that? Even object databases are notoriously better than relational databases for complex queries. For the ScalabilityTest
we have chosen a very simple query on purpose to handicap Prevayler
and give relational databases a better chance. --Klaus Wuestefeld.
Better defining 'trivial' above: supposing you have a List of offices, and a List of employees, you can just walk over them, using reliable and proven technology like the while
loop, which has been around for about 50 years now. Or, if you want to get fancy, try some XPath
Does anyone have an email address of Jonathan Carlson ? I'd like to talk with him about his indexed collection framework and how to bring it together with JXPath
Does Prevayler allow SQL queries, or does it make SQL obsolete? If Prevayler allows SQL queries, will it still be 9000 times faster than Oracle?
Data Warehousing (DW) modeling is going towards UML (objects), check the Common
Warehouse Model and the Gold tool, for instance. -- RogerioDeCarvalho
I have an open-source Swing-based ObjectInspector
that I modified from something Axel Uhl wrote. It's kind of like a Smalltalk inspector. I added a BeanShell
? command window so one could dynamically run methods against the object you are looking at. I have some things I want to improve on it, but it will run OK now. Feel free to ask me for it, maybe it will give me a push to make the modifications.
I also have written a pretty cool (IMHO
that is kind of like a relational database table. That is, it can index a collection of objects in different ways based on the value of a getter method result. Feel free to ask me for it. I keep improving on it as I have time.
I've found a very nice query language to our Java objects: XPath
! I've been using the Jakarta Commons' JXPath
(http://jakarta.apache.org/commons/jxpath/index.html) to dig through my object graphs, and it's a very simple, quick-to-learn language. It fits like a glove on a prevalent project when a lot of different queries are needed. Hey, didn't you always think XML and Java were born to be together? @:)
There's also a demo (see Demos) on how to use it. The demo does not show how to change objects using XPath
, though. Anyone interested in implementing a full JXPath
Here's another very efficient collection library. The hashed collections may use more memory in some cases because it keeps the table size a prime number. But in the case of the primitive hashed collections, the space is reduced so much that it's often a wash.
Trove4J really impressed me! Thanks for the link, Jonathan! -- CarlosVillela
The SODA (Simple Object Database Access) specification looks interesting. I am personally happy to just use the methods on my data objects, but it could be a useful API for the IndexedCollectionFramework
I'm working on.
I am also looking for an efficient in-memory indexing framework, suitable for Prevayler
. Here are
1. Apache/Jakarta's Lucene engine. It looks pretty impressive and you can have in-memory indexes.
The problem is that Lucene has been designed for both disk and in-memory indexing. As a result,
the 'Document' class there is final and you can not associate objects with it.
is just an object graph navigation language. You could use Jexl instead (see jakarta-commons), which offers better Java-like syntax and is better supported (in Jelly and Velocity). The problem is that expression languages alone like the above imply nothing for the underlying object graph and you can not have efficient 'wildcard' queries like in Lucene.
3. Different 'Collections'-like frameworks lack featured query capabilities. Ideally, what we need is a B-Tree in-memory index, where objects can be registered with their
public (bean) properties (and optionally, keywords in the content of the String properties). Than one could look up indexed objects in a simple query language in the index. Time to hack Lucene?
4. I do not think SODA comes with any Collections implementation, just interfaces.
The beauty of SODA is that it does away with queries-as-strings and the need for query parsers.
Just POJOs (plain old java objects -:))!
I am contemplating the idea of writing something along the ideas above, but would like
to see if such projects have not been started already.
run an SQL engine on Java (although I don't want too). You cannot
make queries on ORACLE run faster.
#Your database RESTRICTS
you to using SQL. You might be numb/accustomed to that by now but it is not like you have an option, is it? See: NoMorePorridge
#I don't care if you want tables, indices, triggers and procedures. I want objects.
#If what I wanted was objects in memory, then why would I need a database?
That's precisely the point, thanks.
In anything at all, perfection is finally attained not when there is no longer anything to add but when there is no longer anything to take away, when a body has been stripped down to its nakedness.
Antoine de Saint-Exupéry in Wind, Sand and Stars
Klaus, All your responses are so biased in favor of Prevayler
. I'm finding it dificult to determine what Prevayler
can really do. They way you speak, Prevayler
is perfect in every way unless you are too stupid to realize. Nothing in computing is ever that cut and dry.
Hum interesting, yeap, the thing needs some work, i really think that nobody gets a clear view of what the hell prevayler is or how can someone use it.
Some real documentation needs to be created, with implementation specs, and real working examples using the popular choices: SQL, Xpath, etc... Until then it is just another wierd and exotic open source project, among the millions that exist on this big NET.
What about OQL?
If you have *real* applications, you want fast and independent solutions to findind your objects. OQL was proposed for that.