From: Carl R. <ca...@db...> - 2003-04-24 11:30:25
|
(X-post to sod...@li...) Dave, > SODA appears to be designed to deal with single-rooted object graphs. Can > it query across object graphs with multiple roots? Actually S.O.D.A. doesn't care about roots at all. A S.O.D.A. query queries the entire *unrooted* database. For Prevayler you may consider to have a factory to create a Query object from a Collection. In case you would want to search multiple Collections, you would pass a Collection of Collections as the argument. I don't think a specification of alternative ways of creating Query objects is too important at this point in time. It's a one-time-job to write a wrapper to a different interface. By far the more important aspect of continuing the work on the specification is "How do queries look like?". That's individually different for every single query, so if we do something wrong here, different approaches in different versions would produce incompatibilities. The other problem your brought up is by far more interesting: > For example, suppose I have two TreeMaps, let's call them students and > grades. The students TreeMap is indexed by an Integer value that increments > every time you add an object and stores Student objects. The grades TreeMap > also uses an autoincrementing Integer for its key and stores Grade objects > which tracks a Student object's grade for a class. The Grade objects do not > directly reference Student objects but rather contain the Integer ID for the > Student object in the students HashMap. (This is a fairly common idiom in > Prevayler applications due to the fact that Transactions cannot directly > reference business objects but must look them up at runtime.) > > What I couldn't figure out is how I could use SODA to construct a query that > would return a ResultSet of pairs, where each pair contains a Grade object > and the Student object corresponding to the Grade object. In other words, > how do I do a join operation using SODA? I am afraid we don't have a running solution for your problem yet. Some thoughts how it could look like: // Let's set up the classes first class Student{ int id; String name; } class Grade{ int student; // the id int grade; } // Let's invent the S.O.D.A. query factory for prevalent systems: public class Soda{ public static Query query(Object source); } // Now we can set up two queries, one for students, // one for grades: // (1) Prevayler notation, querying two Maps: Query qStudents = Soda.query(studentMap); Query qGrades = Soda.query(gradeMap); // (2) ObjectContainer notation ObjectContainer oc; // opened somewhere before this code Query qStudents = oc.query(); qStudents.constrain(Student.class); Query qGrades = oc.query(); qGrades.constrain(Grade.class); // We neither have a sample nor an implementation of joins, // but I think it's obvious, how the code to set one up should // look like: qStudents.descend("id").constrain(qGrades.descend("student")); // As your output, you seem to want a "flat" pair of Student and // Grade, very similar to an SQL resultset. We don't have a concept // for that yet, but we will need it for lots of SQL features. // How about this new method in the Query interface: public interface Query{ /** * defines a Query node to be represented as a column in the array * returned for every element of the ObjectSet upon query execution. * @param node the Query node to be represented * @param column the column in the result array */ public void result(Query node, int column); } // Suggestions for a better method name than "result" would // be welcome. (defineResult, setResult, setResultColumn ???) // Now we can do this: qStudents.result(qStudents, 1); qStudents.result(qGrades, 2); // executing the Query ObjectSet os = qStudents.execute(); while(os.hasNext()){ Object res = os.next(); // res should be an array of Object with length 2 // The first array element should be a Student object // The second array element should be a Grade object } How does the above look? Have I forgotten anything? It's very well possible that there could be some undefined behaviour but I guess we will find out during implementation. Kind regards, Carl -- Carl Rosenberger db4o - database for objects - http://www.db4o.com |