From: Paul E. <Pau...@gm...> - 2004-09-09 20:22:12
|
<wal...@ph...> skribis: > Although this project hasn't been active for quite a while, Yes. There is not much to do now ... > I think > you still can help me to verify this comparison. > > I've set up a project, called JavaMatch, to build a matching engine. > You can find JavaMatch at http://javamatch.sourceforge.net > In short, it looks inside a runtime data structure, and tries to find > objects that _best_ match a query (vs. _all_ objects that match the > query, as SODA does). This is an interesting idea. We may think about adding this to our API. > After seeing the SODA query API, I think there > are some similarities and some differences between SODA and JavaMatch. > > Can you please have a look at the list, and see if there are any things > missing, incorrect, or if you have any other comments? > Returned results (The main difference, I'd say) > - SODA returns all objects that match the specified constraints. Yes. > - JavaMatch returns the objects that best match the specified query, > with the best matching object first What does this mean in your "Example 2" from the webpage? > Programming language > - SODA is programming langage independant. Java and C# are supported Since those languages are very similar, it was easy writing an API for both. Of course implementations don't need to be available on both languages. [...] > Comparison operators > - SODA's Constraint interface has a fixed set of evaluation modes. > These can be mapped to / executed by the underlying database system. There is also an ability to use individualized queries: add an Evaluation-Implementation to your Query via .constrain(). (This way the underlying System has to execute your Java (or C#) (byte)code.) > - JavaMatch has a hierarchy of queries, that is executed in the Java > Virtual Machine > > Customizable filtering > - SODA provides the Evaluation interface. When a query is executed, the > Evaluation acts as a final filter on the objects that are returned Hmm. I should read your whole email before answering. > - JavaMatch's queries can be customized by subclassing class MatchQuery > > Runtime member retrieval > - SODA has a Query interface, that describes how to descend from an > object to its members, and to put restrictions on those members > - JavaMatch's Queries that retrieve object members have an argument > "memberName" in their contructor. This is the path that is followed > to retrieve a member value Is there an ability to go furher down in the hierarchy? > Performance > - SODA's constraints can be mapped to operators in the underlying > database. Therefore, they can be executed by the database itself. > The Evaluation leads to data transfer from the server to the client I once had the idea to create an "in-memory-implementation" of SODA, as a reference implementation. But I didn't much to program it. So de facto databases seems to be the only implementations. (Are there others than db4o?) > - JavaMatch operates on the full set of objects. All data is sent from > the underlying data storage mechanism to the Java Virtual Machine > > Collections > - SODA uses an ObjectContainer as a bridge to the data structure > - JavaMatch operates on standard Java collection classes (List, > Iterator) Since SODA is an API for getting Objects out of an database, the database (=ObjectContainer) has to implement it. (My "Memory-based" implementation would be able to use collections.) > Data types > - SODA uses an ObjectSet to return the results > - JavaMatch returns its results as a List One argument for not using a full collection follows: > Memory > - SODA returns the objects one-at-a-time, so the entire database won't > be kept in memory If we had an collection, it would be able to do random access. The ObjectSet is like an Iterator - go once through the results. Another cause is that there should be (and are) SODA-implementations running on JDK<1.1-VMs, without the Collection-Framework. Paul |