|
|
|
 |
|
Sort Order:
Hi Andy,
1. I'll take a look to the db4o implementation, thanks for the hint. 2. Yes. Apache Directory Shared depends on it, and it is a runtime dependency. We use slf4j as wrapper around log4j. Hey, I fully agree with your policy. I was busy the last months, now I will take some time. I'm interested on Object-LDAP-Mapping, and I think it is a good approach to use an existing standard (JDO) and implementation. But maybe I'll disappear again ;-) Patch for store.ldap, relative to platform/store.ldap/trunk
Patch for test.jdo.ldap, relative to test/accessplatform/trunk/test.jdo.ldap
Patch for local.repository, relative to platform/local.repository/trunk
I attached three patches for store.ldap, test.jdo.ldap and the local repository
Additonally please add the following jars to the local repository: Under folders "org.apache.directory/jars/": http://repo1.maven.org/maven2/org/apache/directory/shared/shared-ldap/0.9.13/shared-ldap-0.9.13.jar http://repo1.maven.org/maven2/org/apache/directory/shared/shared-ldap-constants/0.9.13/shared-ldap-constants-0.9.13.jar http://repo1.maven.org/maven2/org/apache/directory/shared/shared-asn1/0.9.13/shared-asn1-0.9.13.jar Under folders "org.slf4j/jars/" http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.3.1/slf4j-api-1.3.1.jar http://repo1.maven.org/maven2/org/slf4j/slf4j-log4j12/1.3.1/slf4j-log4j12-1.3.1.jar patches committed with minor changes due to remove binary linkage to the native query
to run the tests with native ldap queries
mvn clean install -P ldap-native otherwise use mvn clean install -P ldap Patch with minor changes:
* Native query wasn't working, due to missing slf4j dependencies * Added log message when native query fails * Removed some System.out.prinln() I can no longer build using Eclipse.
It tries to bring in /usr/local/eclipse-3.4/plugins/org.apache.directory.studio.jars_1.1.0.v20080331/lib/shared-ldap-0.9.8.jar (for some Eclipse reason). This is brought in via Directory Studio. How do I build in Eclipse now ? You could remove the Directroy Studio plugins in Preferences->Plug-in Development->Target Platform.
I'll investigate if we could reduce the visiblity of the exported packaged in the Directory Studio jars. Thx Stefan, Eclipse builds fine now.
Only comment on the QueryToLDAPFilterMapper : there's a check for method "contains" and a comment that refers to "String" type. The "contains" method is actually for Collection fields as per http://www.datanucleus.org/products/accessplatform_1_1/jdo/jdoql_methods.html and as per the JDK. Oh, ok. I thought that this method means the String.contains() method, then I implemented a test and noticed that it doesn't work, however I forgot to remove the "contains" method.
Patch
* Native query wasn't working, due to missing slf4j dependencies * Added log message when native query fails * Removed some System.out.prinln() * Removed "contains" method in QueryToLDAPFilterMapper.processInvokeExpression() Patch 12-3 applied with the exception of adding slf4j to pom.xml of "store.ldap" - SLF4J is not a DataNucleus code requirement so we don't list it; if Apache Directory needs it to run then it goes in its dependencies.
Patch
* Added support for ParameterExpressions Note: the changes in this patch depends on new methods in org.datanucleus.query.QueryUtils, these new methods are included in Stefan, is this issue complete ? I'm going to do 1.1 M3/1.0.3 releases next week (week starting 4th Dec)
I'll review the code and tests this weekend and update documentation.
Is it possible to add the dependencies to use native LDAP queries to the datanucleus-accessplatform-ldap and datanucleus-accessplatform-full-withdeps distributions? These dependencies are
- shared-asn1-0.9.13.jar - shared-ldap-0.9.13.jar - shared-ldap-constants-0.9.13.jar - slf4j-api-1.3.1.jar - slf4j-log4j12-1.3.1.jar I added these dependencies to the documentation: http://datanucleus.svn.sourceforge.net/viewvc/datanucleus?view=rev&revision=4213 accessplatform zips include LDAP deps now
|
|||||||||||||||||||||||||||||||||||||||
New Feature
Closed
Major
Implement native queries using LDAP filters
having an option to have queries evaluated in LDAP obviously makes sense. Comments :-
1. Look at "store.db4o" src/java/org/datanucleus/store/db4o/query/JDOQLQuery.java for "datanucleus.query.evaluateInMemory". This is used to allow users to evaluate a query in memory (like now), or natively (what you're adding). Add something like that as the way of deciding if they use the current process or yours.
2. slf4j logging : why ? No logging from any of DN should use that, instead NucleusLogger. Obviously Apache Directory code can call slf4j if it wishes, but are these deps you're talking about compile time or runtime ?
3. shared-XXX deps : no problem with those but they should be "optional" (MANIFEST.MF, and pom.xml) so people who just use the current code don't need to include them. They'd also need to go in local.repository.
4. Using AbstractExpressionEvaluator for the process - yes, same basic idea as we had with db4o/NeoDatis.
If you are going to be working an amount of time on store.ldap then I can certainly give you (back) commit rights, just that I've spent 5+ yrs giving ppl rights and then after a couple of commits they aren't seen again. The project needs your time.