LLBL 3.1 - Adapter model through remoting templates - Oracle

I need to create a SoundEx predicate. Based on other posts, I copied the FieldLikePredicate source code into a common library at both the client and server and I fixed up the appropriate query in the ToQueryText method.

I did need to comment out references to a "SelfServicing" object that it couldn't find.

But then at runtime it was complaining that it couldn't turn it into a FieldLikePredicate. Found in the InitClass that InstanceType was being set to FieldLike so I switch it to UnDefined, but now I get an object reference not set exception.

Any ideas?

Can you show the modified code that you used...?

(Do people still use SoundEx...? Always found it spectacularly useless myself )

Matt

It's a lot of code to post. I've attached my latest file.

Also, I made a mistake, this is based on 3.0 code.

I initially copied the FieldLikePredicate. Now I switched to copying the FieldCompareValuePredicate.

But regardless, both cases I'm getting stopped on a line of this type in the ToQueryText method:

parameter = this.DatabaseSpecificCreator.CreateParameter(_field, _persistenceInfo, ParameterDirection.Input, _value);

object reference not set.

my _persistenceInfo is null, we've always set that to null in our code.

The persistenceinfo should be injected into the fields in the dataaccessadapter routine: InsertPersistenceInfo(predicate). If you pick an existing predicate class, it will there assume things based on the type of the predicate. You can set the predicate type to a different enum so the switch ends up in the default clause, where you can add in a code region your own code to inject persistence info for the fields inside your predicate. So, try to inherit from the FieldCompareValuePredicate.

I'm confused.

Everything works great for us, even through remoting with the ll predicate serializing across the connection, and whenever I build predicates at the client, I am setting the peristenceInfo to null as it's calling the IEntityFieldCore version constructor of the predicates.

I commented out some code in my custom predicate, and it's almost there. It's building the right query EXCEPT that it's injecting the bo property name into the where clause instead of the database column name, and that's most likely because I'm getting an exception in my custom predicate on

his.DatabaseSpecificCreator.CreateFieldName(_field, _persistenceInfo, _field.Name, this.ObjectAlias, inHavingClause);

about object not set and all I can think of is it's the persistenceInfo is still null. It doesn't look like the code internally is setting this itself either so why do the other predicates work when I give them null for this but my custom predicate, based on FieldCompareValuePrediate, won't work?

happyfirst wrote:

I'm confused.

Everything works great for us, even through remoting with the ll predicate serializing across the connection, and whenever I build predicates at the client, I am setting the peristenceInfo to null as it's calling the IEntityFieldCore version constructor of the predicates.

Even if you pass null, internally the DataAccessAdapter object inject default persistence information about the fields. So that happen behind the scenes in predicates, even if you pass null to that parameter.

happyfirst wrote:

I commented out some code in my custom predicate, and it's almost there. It's building the right query EXCEPT that it's injecting the bo property name into the where clause instead of the database column name, and that's most likely because I'm getting an exception in my custom predicate ...

Please post your custom predicate class, maybe I can help you to get that working. we didn't see any code so far.

I thought I had attached the source a few posts ago. I will try again.

The line that is throwing the exception for me is:

string fieldName = this.DatabaseSpecificCreator.CreateFieldName(_field, _persistenceInfo, _field.Name, this.ObjectAlias, inHavingClause);

Instead of copying the code, I suggest you derive from any of the existing predicates, and only override the ToQueryText method and call the base class method first, and then you can modify the query text as you like and return the modified string.

Thanks. I "think" I've finally gotten this working.

(not checked any details ) -> the persistence info is injected for 'known' predicates in the DataAccessAdapterBase class. If you write a new predicate which has a type (using the enum) which isn't known to that class, it will call OnInsertPersistenceObjects. You should override that method in a partial class of DataAccessAdapter if you want to continue your own predicate class with your own enum type and inject the info in an override of OnInsertPersistenceObjects. It's however easier to override just a known one, if your predicate structure is equal to a known one (e.g. the predicate has 1 parameter, which is a field)