> > > > OK, this is a VERY good point. But any Query language or system > > > > typically requires a lot of thought to be powerful, yet reasonably > easy > > > > to implement. Let us discuss that later/separately. > > > > (& (objectClass=block) (service=o.a.a.DataStore) (version>1.0) > > > (| (container=Merlin) (container=Phoenix) ) ) > > > > I would like to see you implement that for any type of repository, CVS > for > > instance?
> Maybe I wasn't clear enough. I think I did not make sense either. Let me start from scratch by saying you define your API to ask the database questions. No query passing here. Just things like list groups, give me all the dependencies. Or give me all the attributes associated with an artifact. This is the database interface but it does not have methods that take a filter or query. For example I might have a method getAllDependencies(). This may translate in the implementation into the execution of a query to find this information yet we do not pass in the query. The implementation under the hood talks to a database to query it for these attributes. The database that best fits the job here IMHO is a directory and LDAP is what I'm thinking. This is a very repo specific API. Another approach could be to use an existing and generic access interface like JNDI. You could design a special JNDI provider for the repository and use that for your access model. Then if you felt like it you can support directory interfaces conduct searchs using any kind of filters you devise. So this is yet another approach to build an interface around a repository directory with meta data. > For a Query system to work, it is important that; > 1. There is a solid user API contract, preferably easy to use. > 2. The query implementation for each repository type is reasonably easy to > implement. > 3. The implementation could pass the query, full or in part, to the > server, to > lower network activity. > So, what I am saying, the Query discussion will continue beyond my first > use-case, i.e. it is a separate use-case and handled accordingly. Ok with me. I have a couple of things that I'm trying to manage now too with the spi, api, impl split in the repository. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
