• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Querying object from a collection

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to create my own collection type that allows querying for an object based on:
a) it's type
b) the template provided (aka fields).
I'd also like to be able get obtain a match even if not all the fields are specified (aka. a field is null). Also it should be able to get all possible matches based on the template.
What would be a good way to tackle this problem? By default, hashtables or maps don't seem like the ideal way to go even if I worked out a way to layer them. Maybe they are... I feel stuck on the logic of the problem then the actual implementation details (ie. reflection, etc).
 
Sheriff
Posts: 6965
2
Eclipse IDE Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This sounds a lot like JavaSpaces. A JavaSpace is a data stre which is queried by supplying an object template in the way that you discuss.
Go to java.sun.com, and check out their JavaSpaces resources. I believe source code is available too.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Arendt:
I want to create my own collection type that allows querying for an object based on:
a) it's type
b) the template provided (aka fields).
I'd also like to be able get obtain a match even if not all the fields are specified (aka. a field is null


Let's forget about type for the moment. Let's also just focus on the algorithm expressed in terms of Collection classes. Since you need to be able to search on any number of fields, you may initially index each field separately. For each possible value of the field, you have a set of objects which have that value.
Enter a HashMap which maps a value to a Set of objects. For each non-null field in your template, you would be doing something like this:

Each field would have its own fieldValueMap. This calls for a further Map which maps the name of the field to the fieldValueMap.
So far, so good. There is a fair number which will complicate things however.
First, if you want to be able to search for a range of values in a field rather than a fixed value only, you would need to use a TreeMap instead of a HashMap.
Second, you will probably find that for some fields indexing doesn't work. They only have a few values and you will end up with impossibly large and inefficient Sets for that field. These fields would better be subject to a linear search. You could enhance the code so that it will do a linear search where the fieldValueMap is null.
Third, once you've gone through a couple of fields, your resultSet is likely to be so small that a simple linear search through the remaining set is more efficient than going through the fieldValueMap for all the remaining fields. In fact, for optimum performance you would process the template fields in an order that allows you to cut down the resultSet as quickly as possible and finish off with a linear search.
If the above sounds like database indexing and query optimisation, that is because that's essentially what you're trying to build: an in-memory database. I would advise you to take a long hard look at products like the (free) HypersonicSQL.
Fourth, types. If you don't want to compare between types, it's simple -- instead of mapping the field name to a fieldValueMap, you map typeName.fieldName to a fieldValueMap.
This can even be made to work when comparing different but compatible types. Say you have a class A with field a, and subclasses B and C. Say you are adding an object of type B. You can use reflection to determine that field B.a is in fact inherited from A, and map it using "A.a" rather than "B.a". That way, if you are searching with a template of type A, you will find not only objects of type A but also matching objects of types B and C.
Hope I didn't discourage you!
- Peter
 
James Arendt
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frank, thanks for the suggestion. I'll take a look at how JavaSpaces handles it to see if I can get any ideas or perhaps optimizations/simplifications related to Peter's suggestion.
Peter, no, I'm not discouraged. I didn't expect it to be all that simple. I knew I was in a sense creating a simplistic in-memory database. One of the main reasons I've avoided using a database is that I'm trying to keep it as lightweight as possible.
I haven't had time to go over your suggestion in depth yet (on my way to work in a few moments) so I'll have to comment more on that later.
 
James Arendt
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, got sometime to look things over a lil' bit.
Glancing over the JavaSpaces source and ignoring the transactional aspects, they seem to be heading the direction Peter was suggesting. In some parts, they do actually use lists, however, they do note that for non-simple cases (ie. larger number of entries) hashing will be more appropriate which stays in-line with Peter's suggestions.
So, Peter, it looks like I'll be using your suggestions as a guideline. I'm pretty sure I follow the logic so at the moment I don't think I have any further questions, though I won't shy away from being open to receiving any more tips or suggestions. I think a lot of it will just turn out to be implementation details, deciding what tradeoffs I want to make, and well, a bit of time.
One more thing... If anything, it'll be quite a learning experience.
[This message has been edited by James Arendt (edited March 08, 2001).]
 
reply
    Bookmark Topic Watch Topic
  • New Topic