Last possible 2.1 change (and I mean it this time!)Last possible 2.1 change (and I mean it this time!)
Old forum URL: forums.lhotka.net/forums/t/1155.aspx
RockfordLhotka posted on Thursday, September 07, 2006
I'm nearing the release of a real beta of 2.1 - ideally tomorrow.
However, I'm seriously contemplating one big change and would value timely input. It is a tough decision.
Back in 2.0.2 I altered the way the data portal calls DataPortal_Create() and DataPortal_Fetch(), specifically when you pass no criteria parameter or Nothing/null. When I did this, I tried to minimize backward compatibility issues - but the end result is a non-intuitive mess, that appears to be the cause of more support questions than even Remoting... (which is saying something!)
So in 2.0.2+, the following mappings occur for DataPortal.Create() (and Fetch()):
DataPortal.Create() --> DataPortal_Create(object)
DataPortal.Create(null) --> DataPortal_Create(object)
DataPortal.Create(criteria) --> DataPortal_Create(criteria) or DataPortal_Create(object)
What should happen to match normal calling semantics is:
DataPortal.Create() --> DataPortal_Create()
DataPortal.Create(null) --> DataPortal_Create(object)
DataPortal.Create(criteria) --> DataPortal_Create(criteria) or DataPortal_Create(object)
Again, the same for Fetch().
There are two big impacts involved here.
First, making this change would break all existing Create() and Fetch() calls (with no parameter). Other Create() and Fetch() calls should continue to operate.
Second, the virtual/Overridable declaration of DataPortal_Create(object) in all base classes would become totally useless - counterproductive even - since most Create() calls are parameterless (or should be). I'd want to change the base class definitions for this method - and that too would break almost every class out there.
So the question is whether it is worth it. I lean toward saying yes - because it is very clear that my 2.0.2 change has created a highly unintuitive mess. But at the same time, I fully realize the upgrade pain from 2.0 to 2.1 that I'd be creating (though I think that most of the changes could be made by a single mass-subtitution across all your class files).
Thoughts?
RangerGuy replied on Thursday, September 07, 2006
Sounds like a good idea to me. If it means a "cleaner" more intuitive frame work. I'm willing to work late and make that change in my system :)
ajj3085 replied on Thursday, September 07, 2006
I think you should make the changes. Yes, there will be pain, but the benefits gained from being more consistent will be worth it. Clarity in frameworks is very important, and if this has become a huge support issue, I'd rather you break everyone else's code so that you can spend more time on, well, whatever you decide is important.
Brian Criswell replied on Thursday, September 07, 2006
ajj3085:I think you should make the changes. Yes, there will be pain, but the benefits gained from being more consistent will be worth it. Clarity in frameworks is very important, and if this has become a huge support issue, I'd rather you break everyone else's code so that you can spend more time on, well, whatever you decide is important.
Agreed. Compile time breakages are easy to deal with, and other changes are okay as long as you know the upgrade path.
tetranz replied on Thursday, September 07, 2006
Brian Criswell: Agreed. Compile time breakages are easy to deal with, and other changes are okay as long as you know the upgrade path.
I say go for it, otherwise you'll always be kicking yourself later and it can only get to be more of a pain for more people as time goes on.
But ... just to be clear, is this a runtime breakage or compile time?
Cheers
Ross
RockfordLhotka replied on Thursday, September 07, 2006
The change to the virtual methods in the base classes are a
compile-time breakage.
The changes to invoking DataPortal_Create() vs
DataPortal_Create(object) are a runtime breakage. However, the most likely
scenario is that your existing DataPortal.Create() call is calling the override
of the virtual method, so (I think) you'll always get a nod that you have a
problem at compile-time.
Rocky
But ... just to be clear, is this a runtime breakage or
compile time?
Jav replied on Thursday, September 07, 2006
Better to do it now than to always fret about it. I don't think any of us has "released" a product since 2.0.2. As for fixing things - that's what we are doing all day anyway - one more fix aint gonna kill no one. ![Smile [:)]](/emoticons/emotion-1.gif)
Jav
Michael Hildner replied on Thursday, September 07, 2006
RockfordLhotka: I fully realize the upgrade pain from 2.0 to 2.1 that I'd be creating (though I think that most of the changes could be made by a single mass-subtitution across all your class files).
One more "Yes" vote. Especially if it's as easy as a ctrl-h. Although I'm not clear either if it's a compile-time break or a runtime break - the latter scares me a little.
Also, since I'm charging by the hour on this project, it's okay with me if you want to make it more difficult to fix :)
Client: What do you mean it's going to cost me an extra $1000?
Me: Don't blame me, it's that dang Lhotka guy. It's still a lot cheaper if we hadn't used CSLA in the first place.
They'll pay.
ajj3085 replied on Friday, September 08, 2006
Michael Hildner:One more "Yes" vote. Especially if it's as easy as a ctrl-h. Although I'm not clear either if it's a compile-time break or a runtime break - the latter scares me a little.
Why would a runtime break scare you? You DO have unit tests, right?
![Wink [;)]](/emoticons/emotion-5.gif)
Michael Hildner: Also, since I'm charging by the hour on this project, it's okay with me if you want to make it more difficult to fix :)
Client: What do you mean it's going to cost me an extra $1000?
Me: Don't blame me, it's that dang Lhotka guy. It's still a lot cheaper if we hadn't used CSLA in the first place.
They'll pay.
Ahh.. I guess you don't have unit tests then.
Michael Hildner replied on Friday, September 08, 2006
LOL Andy.
You're right, I don't have unit tests. Well, actually I have about 4 of them, which haven't been run for months.
I was unable to convince the guy I'm working for that we should have tests. I tried, I guess not good enough. Seems he didn't want to pay for something he didn't understand. It was bad enough the first couple-three weeks into the project when I was creating all the classes, sprocs and DB stuff. Absolutely nothing to show in terms of UI. All that "back end" stuff means nothing to the client - they want something they can touch and see. Kind of a tough position. My project isn't perfect, but it could be worse.
Mike
ajj3085 replied on Friday, September 08, 2006
Mike,
Definately hear you on those points. Some clients are just tough to work with. I'm not sure how to better explain to those clients that there's much more that just a pretty UI that needs to be built. Did you attempt to show him the database design or class design? Even if they don't understand it, you might be able to say 'this is how your data is stored and this is how the application knows how to perform tasks.'
At any rate, my post was simply meant to get a laugh, and it seems that it did.
Andy
vbLuis replied on Wednesday, September 13, 2006
I happen to use DataPortal_Create with a Criteria object. (I often pass one or more values via the Criteria object.) So, if I understand this correctly, all I have to do to be compatible with Csla 2.1 is remove the Overrides in the DataPortal_Create declaration of my derived class and it should still work?RockfordLhotka replied on Wednesday, September 13, 2006
Yes, that is correct.
Rocky
I happen to use DataPortal_Create with a Criteria object. (I often
pass one or more values via the Criteria object.) So, if I understand this
correctly, all I have to do to be compatible with Csla 2.1 is remove
the Overrides in the DataPortal_Create declaration of my
derived class and it should still work?
JoeFallon1 replied on Thursday, September 14, 2006
RockfordLhotka:
Yes, that is correct.
Rocky
I happen to use DataPortal_Create with a Criteria object. (I often pass one or more values via the Criteria object.) So, if I understand this correctly, all I have to do to be compatible with Csla 2.1 is remove the Overrides in the DataPortal_Create declaration of my derived class and it should still work?
Sorry to be dense here but I am not getting a clear picture of this issue.
BusinessBase looks like this:
Protected Overridable Sub DataPortal_Create(ByVal criteria As Object)
I use split classes and my Base class looks like this:
<RunLocal()> _
Protected Overrides Sub DataPortal_Create(ByVal criteria As Object)
If I want to Override it in my final type I can easily do so. Plus I can decide whether or not to RunLocal in the final type.
Question 1 - What do you propose changing BusinessBase too?
Question 2 - What would my Base class method look like after the change? This?
<RunLocal()> _
Protected Overridable Overloads Sub DataPortal_Create(ByVal criteria As Object)
Joe
ajj3085 replied on Thursday, September 14, 2006
BusinessBase is changed from:
Protected Overridable Sub DataPortal_Create(ByVal criteria As Object)
to
Protected Overridable Sub DataPortal_Create()
Your base class will look like:
<RunLocal()> _
Private Sub DataPortal_Create(ByVal criteria As Object)
Fabio replied on Thursday, September 14, 2006
Hi.
What happened with Delete?
DataPortal.Delete(null) --> DataPortal_Delete(object)
DataPortal.Delete(criteria) --> DataPortal_Delete(criteria) or DataPortal_Delete(object)
Can we have the same behaviour of Fetch for strongly typed criteria?
Fabio.
Copyright (c) Marimer LLC
