Re: [Sodaquery-general] Compare SODA-query and JavaMatch

[<wal...@ph...>]

Hi Paul,

>> - 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?

You're right, it wasn't really clear there. I've updated it. In short:
- First it finds the objects that exactly match, similar to the result of 
a
  SODA query
- Then it finds the objects that match the best, those objects that meet 
  3 out of the 4 subqueries, then 2 out of 4,  etcetera.

>> - 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?

In the Prevayler demo 
(http://javamatch.sourceforge.net/integration.html#prevayler), 
and in release 0.2 (due next week), you can use things like 
"transactionHistory().size()". 
In release 0.3, I want to handle collection classes, to support 
"match if collection ... has an object that contains ..." and 
"sum of the results of calling member ... on all objects in ...".
I'm still thinking about an understandable syntax for this.

> If we had an collection, it would be able to do
> random access. The ObjectSet is like an Iterator
> - go once through the results.
That's more logical for SODA indeed. Easier to implement in the 
underlying database. Makes it even possible to search in the database only
when the caller requests it. java.sql.ResultSet also works like an 
Iterator.

JavaMatch has to process all data in the database in advance, to find the 
best matching objects. While matching, it maintains a list with the best 
matching objects. This list is simply returned.

> Another cause is that there should be (and are)
> SODA-implementations running on JDK<1.1-VMs,
> without the Collection-Framework.

Very valid reason, especially for embedded devices.

Regards,
Walter