Naming conflicts between custom and generated operations

[GoogleCodeExporter]

Given a table [Unit], with a column called [UnitIdentifier]... 

-- the developer creates a custom procedure [csp_Unit_GetByUnitIdentifier] and 
performs a code generation...

--- at some point after that initial code generation, an index is added for the 
[UnitIdentifier] column.

--- any subsequent code generation attempts will produce code that will not 
compile due to the 'GetByUnitIdentifier' method existing twice. 

Ideally, the custom procedure should 'override' the generated operation rather 
than creating duplicate methods.  

Understandably, there may be a few cases where this should not be allowed 
unless the custom procedure adheres to the original method signature. I.e. 
allow the Insert/Update/Delete to use a custom procedure so long as it accepts 
the same arguments and returns the same results...  

In our particular example, the index-based method was returning a TList<T> 
whereas the custom procedure was returning a DataSet... therefore the method 
signature should match what the custom would generate... Otherwise, for cases 
where the return-type is the same, we just keep those custom procedures in an 
'overrides' folder taht doesn't get applied to the code generation database but 
does on the actual runtime databases...

Original issue reported on code.google.com by bh...@questis.com on 17 Sep 2010 at 4:56

[GoogleCodeExporter]

Hello,

I agree with you on this. However, just using the custom stored procedures for 
all the CRUD operations could cause bugs in the code depending on what is going 
on inside of the stored procedure. Have you created a patch for this?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 21 Sep 2010 at 12:11

• Changed state: AwaitingInfo

[GoogleCodeExporter]

Unfortunately lack of time and familiarity with the templates prevents me from 
tackling this... I hope to at some point have time to dig in & learn CodeSmith 
and the NetTiers templates to a point where I could entertain making this type 
of contribution!

I agree with your comment on the operations... I think that's part of the 
analysis/design of this change that will be challenging...  I think the key is 
that the user is responsible for knowing what they're doing... you can't 
prevent someone from doing something plain stupid... they'll learn the hard 
way.   

I think for the most part the Insert/Update/Delete operations might be 
hands-off unless they adhere to the expected interface (same return/input args) 
but any other case allow the custom to 'trump' the generated operation...

Original comment by bh...@questis.com on 21 Sep 2010 at 5:33

[GoogleCodeExporter]

Original comment by bniemyjski on 21 Sep 2010 at 8:43

• Changed state: Accepted

[GoogleCodeExporter]

Reviewing old items I logged to follow-up and check for progress...

Original comment by bh...@questis.com on 8 Jun 2011 at 5:21

[GoogleCodeExporter]

Hello,

We are actively working on .netTiers 3.0 and got a lot done last week with 3.0. 
We will be putting a preview out this summer and are looking over all issues. 
Please note that the "active" open source .netTiers team is small and we work 
on this in our free time. We could really use any and all extra hands in 
developing 3.0. Are you interested?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 5 Jul 2011 at 2:57