Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> [SOLVED] HUGE problem - Need a work around
 

Pages: 1
Bugs & Issues
[SOLVED] HUGE problem - Need a work around
Page:1/1 

  Print all messages in this thread  
Poster Message
Stoop
User



Location:
Reno, Nevada
Joined on:
28-Feb-2004 12:01:28
Posted:
66 posts
# Posted on: 12-Aug-2004 19:22:42.  
I just updated to the new version today, and discovered that one of the fixes completly broke my code. The fix I'm referring to is:

"Adapter: TypedList.GetRelationInfo() now returns a new RelationPredicateBucket object instead of an existing one. The old situation lead to errors when the GetRelationInfo() was used in a loop and a predicate was added to the PredicateExpression in the bucket. "


I'm sure it solved the above mentioned problem, but it another scenario it causes others. Let me explain.. I use the IRelationPredicateBucket as a property in many classes to reduce code redundancy as I may have a bunch of methods that tap into the same bucket/ common methods:

Private ReadOnly Property FilterBucket() As IRelationPredicateBucket
Get
Return NameValueList.GetRelationInfo
End Get
End Property

I might have one method that looks like this:

Public Function GetNameValueList(ByVal MaxNumRecords As Int32, _
ByVal SortFieldIndex As AvailableSortFields, _
ByVal SortType As Int32, _
ByVal AllowDuplicates As Boolean, _
ByVal FilterFieldIndex As FilterFieldsIndex, _
ByVal FilterCompareOperator As CompareOperator, _
ByVal FilterValue As Int32) As PropertyItemsNameValue
Dim SortExpression As ISortExpression = New SortExpression(SortClauseFactory.Create(CType(SortFieldIndex, PropertyItemFieldIndex), CType(SortType, SortOperator)))
Me.FilterBucket.PredicateExpression.Add(PredicateFactory.CompareValue(CType(FilterFieldIndex, PropertyItemFieldIndex), CType(FilterCompareOperator, ComparisonOperator), FilterValue))
Return FetchNameValueList(MaxNumRecords, SortExpression, AllowDuplicates)
End Function

I have other functions which are similar that also call the method 'FetchNameValueList':

Private Function FetchNameValueList(ByVal MaxNumRecords As Int32, _
ByVal sorter As ISortExpression, _
ByVal AllowDuplicates As Boolean) As PropertyItemsNameValue
Me.adapter.FetchTypedList(NameValueList.GetFieldsInfo, NameValueList, Me.FilterBucket, MaxNumRecords, sorter, AllowDuplicates)
Me.AddNameValues(Me.NameValueList, NameValuePairsIndex.NameColumnIndex, NameValuePairsIndex.ValueColumnIndex)
Return Me
End Function

The problem lies in using the property 'Me.FilterBucket', which (in the new version) created a NEW RelationPredicateBucket object which in turn blows away the PredicateExpression I need that I added in the 'GetNameValueList' method.

Since I'm 4 months into the project, plus another project I'm working on taps into this project's business objects, I need to come up with some sort of work around to avoid a new RelationPredicateBucket object being created everytime the FilterBucket property is called.

Otherwise, I'll be stuck with the older version since the projects are too far along to go in and redo the code everywhere...

sigh... I guess one man's fix is another man's curse..

Steve


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37313 posts
# Posted on: 12-Aug-2004 20:25:14.  
Well, first of all, the problem WAS huge, the fix solved it.

Your code relies on a bug, and I'm sorry, but I'm not going to undo a fix
there is no need for that either, here's how.

Code:


' in the class definition members list:
Private _filterBucket As IRelationPredicateBucket = Nothing

' your new FilterBucket property:
Private ReadOnly Property FilterBucket() As IRelationPredicateBucket
Get
    If _filterBucket Is Nothing Then
        _filterBucket = NameValueList.GetRelationInfo
    End If
    Return _filterBucket
End Get
End Property

The rest of the code can be the same.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Stoop
User



Location:
Reno, Nevada
Joined on:
28-Feb-2004 12:01:28
Posted:
66 posts
# Posted on: 12-Aug-2004 21:34:16.  
Well, I wasn't asking for you to undo your fix.

However, I am going to assume that I am probably not the only one who's code has (or will if they update) been broken. There was nothing wrong with my code - the problem is that the LLGen code had a problem (in loops) and indirectly the fix for this problem broke perfectly good code that had nothing to do with loops.

I'm not an expert, nor will I pretend to be on how you coded the fix to automatically create a new RelationPredicateBucket, but it seems to me that maybe this could have been done with a parameter or overloaded thus allowing exisitng code to continue to work. For example:


Type
dList.GetRelationInfo() 'Same as old way
Type
dList.GetRelationInfo(True) ' Creates a new object
Type
dList.GetRelationInfo(False) ' Does not create new object

In my humble opinion, this fix, though it solved looping problem, should have been aimed at only those situations where looping is involved, and taking into mind more backwards compatibility first..

Thank you for your new property. I will keep it in mind. I still have to go redo about 65 code files to get my project to work correctly with your new version...

Steve


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37313 posts
# Posted on: 12-Aug-2004 21:48:31.  
Stoop wrote:
Well, I wasn't asking for you to undo your fix.

However, I am going to assume that I am probably not the only one who's code has (or will if they update) been broken. There was nothing wrong with my code - the problem is that the LLGen code had a problem (in loops) and indirectly the fix for this problem broke perfectly good code that had nothing to do with loops.

No, the code was wrong. The relationpredicate bucket returned could be altered by a given routine (you did that), which could have an affect on other code requiring a clean bucket. After adding a predicate to the bucket, the call to GetRelationInfo() didn't return the proper bucket, but one with wrong info. That's why the fix was applied.

Quote:

I'm not an expert, nor will I pretend to be on how you coded the fix to automatically create a new RelationPredicateBucket, but it seems to me that maybe this could have been done with a parameter or overloaded thus allowing exisitng code to continue to work. For example:

Type
dList.GetRelationInfo() 'Same as old way
Type
dList.GetRelationInfo(True) ' Creates a new object
Type
dList.GetRelationInfo(False) ' Does not create new object

In my humble opinion, this fix, though it solved looping problem, should have been aimed at only those situations where looping is involved, and taking into mind more backwards compatibility first..

No, because it would make the bug a feature and that was with this particular bug not the intention or wanted. I feel sorry you got hurt by the decision to fix it properly.

Quote:

Thank you for your new property. I will keep it in mind. I still have to go redo about 65 code files to get my project to work correctly with your new version...

VS.NET won't allow you to global search/replace code over more than 1 line, but some editors will. If you have f.e. homesite laying around, you can load the code files in that editor, and global replace the property. Saves you a lot of time.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
uydo
User



Location:
dallas,tx
Joined on:
09-Dec-2003 21:33:50
Posted:
43 posts
# Posted on: 16-Aug-2004 22:33:04.  
Code:

VS.NET won't allow you to global search/replace code over more than 1 line, but some editors will. If you have f.e. homesite laying around, you can load the code files in that editor, and global replace the property. Saves you a lot of time.



... Or even with TextPad, which is a freeware text editor, you can replace all of the changes in all *.cs or vb files within seconds.
  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.