New Posts New Posts RSS Feed: EntityListManager Filters whole table out
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

EntityListManager Filters whole table out

 Post Reply Post Reply
Author
Real View Drop Down
Newbie
Newbie


Joined: 16-Nov-2007
Location: Canada
Posts: 6
Post Options Post Options   Quote Real Quote  Post ReplyReply Direct Link To This Post Topic: EntityListManager Filters whole table out
    Posted: 12-Nov-2008 at 5:15am
Hi,
 
I have a case where I load a table and it seems the EntityList Manager filters out the whole table.  Here is the code excerpt:
 

         RdbQuery query = new RdbQuery(typeof(DofBank));

         query.AddClause(DofBank.IdEntityColumn, EntityQueryOp.EQ, "0001");

         DofBank bank = mOraclePersistor.GetEntity<DofBank>(query);

         Assert.AreEqual<bool>(false, bank.IsNullEntity);

 

(1)      ReadOnlyEntityList<DofCheque> cheques = bank.DofCheques;

         manager = (EntityListManager<DofCheque>)cheques.ListManager;

(2)      manager.Filter = delegate(DofCheque chequ) { return true; };

(3)      manager.RefreshAllLists();

 
I have two tables DofBank and DofCheque with a master/detail relation defined in the ORM from DofBank to DofCheque.  I load the bank and it works fine.  When I load the cheque through the relation (1), I have 0 cheques in the list (there are 4,931 records in the DB).  If I extract list manager and set a passthrough filter (2), the list is properly filled with the records after a refresh (3) and the "cheques" variable now has the 4,931 records.
 
I am at a loss as to what the default filter does.  The relation is on a single CHAR column.  The Sql statement set in the log is exactly what I would expect.
 
Environment:
 - IdeaBlade 3.6.3.4
 - Visual Studio 2008
 - Visual Studio Unit Testing Environment
 - Accessing an Oracle database; I noticed the same behavior using a SqlServer database.
 
Has anyone found something like this before ?
 
Thank you
Back to Top
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374
Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post Posted: 13-Nov-2008 at 2:14pm
The default filter specifies that, to be included in the list bank.DofCheques, a cheque must have a value of "0001" in the property that is its foreign key relating it to DofBank. If there are no DofCheque entities that meet this condition, you get 0 records in the list.
 
When you replace the default ListManager with yours, it says any cheque will do, whether or not it is related to bank 0001; so you get all 4931 of them.
 
 
Back to Top
Real View Drop Down
Newbie
Newbie


Joined: 16-Nov-2007
Location: Canada
Posts: 6
Post Options Post Options   Quote Real Quote  Post ReplyReply Direct Link To This Post Posted: 13-Nov-2008 at 2:20pm
Greg,
 
There is a misunderstanding here.  The table has over 20,000 entries.  4,931 is the number of entries whose key matches the criterion.  The Sql statement in the log provides the correct criterion on the load.  If I load the table directly spefifying this criterion, it returns the 4,931 entries.
 
So it has to be something else.
Back to Top
Real View Drop Down
Newbie
Newbie


Joined: 16-Nov-2007
Location: Canada
Posts: 6
Post Options Post Options   Quote Real Quote  Post ReplyReply Direct Link To This Post Posted: 13-Nov-2008 at 2:31pm
Dave,
 
I just thought of something.  The relation is on a character field.  This field is not defined with the same length in the parent and in the child (an anomaly that you often encounter in legacy databases such as this one and there is nothing I can do about it).  I noticed that, when IdeaBlade loads a character value in a field it does not truncate the trailing blanks.  The provided key is "0001" but it is likely to be returned as "0001                " in the loaded object.  If the filter does not trim before making the comparison, it will reject all the records.
 
Assuming that such is the case, how may I solve this problem ?
 
Thank you
 
Réal
Back to Top
GregD View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 374
Post Options Post Options   Quote GregD Quote  Post ReplyReply Direct Link To This Post Posted: 13-Nov-2008 at 3:15pm
Originally posted by Real

Greg,
 
There is a misunderstanding here.  The table has over 20,000 entries.  4,931 is the number of entries whose key matches the criterion.  The Sql statement in the log provides the correct criterion on the load.  If I load the table directly spefifying this criterion, it returns the 4,931 entries.
 
So it has to be something else.
 
 
Whatever other issues may be in play, it seems to me you're likely to have problems if the rules defined by the new ListManager don't include the one about the foreign key value.
 
 
Back to Top
Real View Drop Down
Newbie
Newbie


Joined: 16-Nov-2007
Location: Canada
Posts: 6
Post Options Post Options   Quote Real Quote  Post ReplyReply Direct Link To This Post Posted: 14-Nov-2008 at 7:58am
Greg,
 
I finally solved the problem and here is what was done:
 
1. The problem was indeed related to the fact that the child column has trailing blanks at the end.
 
2. Not being able to modify the database, I overrode the property in the child record and trimmed its value in the getter.
 
3. This would not work either.  After some experimenting, I discovered that the Entity.GetColumnValue() method does not go through the business object to get its value.
 
4. The Entity.GetColumnValue() being virtual, I overrode it in the abstract business object we use as a common base to all our business objects and extracted the value be reflection from the entity property itself.
 
When I do this, the loading of the child entities from the parent works just fine.
 
In my opinion, it is a bug that the Entity.GetColumnValue() method (at least the version accepting a column name) does not go through the business object property overrides to fetch its value.
 
I thank you very much for the help you provided and the time spent examining this problem.
 
Real
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down