By Alex Luyando - 2/9/2010
So, if I want a BO that will be populated via a stored procedure, do I really need to create a view or table just so the BOM has something to map to? I can envision CFPs coming to the rescue, except that seems like a lot of work to do v. setting up a view.
No biggie... just wondering if there's an efficient way to avoid cluttering up the back end.
TIA
|
By Trent L. Taylor - 2/9/2010
Better solution:
Create a Database Deployment Toolkit project that you never deploy and it will in effect create the CFPs for you, but it is far easier to maintain. This is what I do when I create a SPROC that is returning a result set that isn't defined by a table, view, etc. It works great and saves a lot of time!
|
By Charles R Hankey - 2/9/2010
Thank you both for these posts - lightbulb just went off with a lot of possibilities. Since, if I'm not mistaken, you can deploy just the sprocs from the DDT you could actually maintain the sprocs that filled the pseudo tables right in the DDT project, no?
|
By Greg McGuffey - 2/9/2010
I think the key idea is that you need to create another DDT project just for the CFPs (?)(I assume the schema that will be returned by the sproc). In you regular DDT project, you'd define the sprocs (along with everything else that actually gets deployed to the server). At least that's how I read it. Cool idea too! 
|
By Charles R Hankey - 2/9/2010
Hey Greg -
At first I was thinking just what you posted. But then on further reflection, if you a DDT project just for structures that never actually deploy to the backend, why not maintain the corresponding sprocs ( which will return exactly what the "table" says they should have ) right in the same DDT project with the psuedo tables they represent. Then the only thing you deploy from that project is the sprocs.
Either way works, of course, I just felt drawn to having the DDT project self-contained in this way.
|
By Trent L. Taylor - 2/9/2010
Charles,
Correct. Generally when I create a "fake" table to which I am only going to map by BOs, I generally create another profile so it doesn't dirty the actual profile or database itself (as Greg mentioned). But this is a very useful way to create CFPs easily when it will be lining up with a SPROC.
|
By Edhy Rijo - 2/9/2010
Charles R Hankey (02/09/2010)
...But then on further reflection, if you a DDT project just for structures that never actually deploy to the backend, why not maintain the corresponding sprocs ( which will return exactly what the "table" says they should have ) right in the same DDT project with the psuedo tables they represent. Then the only thing you deploy from that project is the sprocs.
Charles, I believe the problem is that you cannot select which SP will be deployed at the DDT, it is all or nothing, hopefully that would change with the upcoming overhaul. Also I found easier to have the DDT project just dummy tables, I make use of the "Category" to group all the DDT projects for one SF project.
|
By Charles R Hankey - 2/9/2010
But in the scenario I'm describing I would want to deploy all the sprocs - they would be the sprocs that represented all the structures in my structure only DDT project. Are you saying they would mess with existing sprocs or remove sprocs deployed by the main DDT project which is maintaining the apps real data ? Maybe I'm misunderstanding how it all works, but I thought I could deploy just the sprocs from a project and existing sprocs wouldn't be touched. No?
|
By Trent L. Taylor - 2/9/2010
There may be a bit of confusion. But let's just recap, if you decide to create a pseudo table to which a BO will be mapped in a live profile, you cannot prevent that table from being deployed. That was the point I was trying to make and all I was getting at in regards to the SPROCs.
|
By Charles R Hankey - 2/9/2010
I completely get that. My question is, do you see any problem with having a DDT project that is structure only, maintaining the sprocs for those structures in that same DDT and then only deploying the sprocs to a database which is otherwise being maintained - schema and sprocs - by the DDT that actually represents the real tables.
Can just the sprocs be deployed from the structure only DDT project without messing with the sprocs that have been deployed from the primary DDT project ?
|
By Trent L. Taylor - 2/9/2010
I am not sure why you would want to do that so I might be missing your logic here. But as for the results, not really. There is an extended property tied to each sproc. So when one PKG deploys on top of the other, the key of the previous will remove the sprocs of your primary PKG file.
|
By Charles R Hankey - 2/9/2010
It seems it would be convenient to write the sproc in the DDT while having the data structure right there. Structure and sproc that fills it would live in the same DDT package.
It is the extended property key I was concerned about. If I deploy sprocs from primary ddt then deploy sprocs from structure ddt ( different named sprocs ) will the primary ddt sprocs survive.
Of course the best way it to try it.  My test project almost finished, I'll post results.
Thanks for your patience.
|
By Alex Luyando - 2/10/2010
Wow... Pandora's box! But I think I'm getting what I need (essentially that it may be time to play with the DDT).
Thanks for the posts/ideas.
|
By Alex Luyando - 2/10/2010
Trent L. Taylor (02/09/2010)
Create a Database Deployment Toolkit project that you never deploy and it will in effect create the CFPs for you, but it is far easier to maintain.
Oh, and this implies the answer to another related question: No problem having a BO that is comprised exclusively of CFPs, correct?
|
By Trent L. Taylor - 2/10/2010
Correct.
|
By Charles R Hankey - 2/13/2010
I tested my idea of keeping the sprocs that would fill tableless BOs that only exist as DDT structures in a project created for that purpose. The idea was to keep the sprocs with the DDT project that contained the structures described in them, then just deploy the sprocs, not the structures to the table
BAD IDEA
While the DDT will let you deploy just sprocs and you can point it to a Database that is otherwise created and maintained by a primary DDT project, deploying those sprocs from the dummy DDT will, in fact, wipe out the sprocs maintained and deployed by the primary DDT project.
Sooo, Table structures only in dummy DDT project so the BO mapper has something to point to. That DDT project never gets deployed.
SProcs that will be used to fill the BOs mapped to the dummy DDT will live with all the other sprocs deployed from the primary DDT project. Since the DDT lets you have more than one project open and you can easily flip back and forth there is really no advantage to doing what I was trying to do, even it if worked.
|
By Les Pinter - 2/13/2010
Hi Charles, It's a wise man who admits his mistakes. I'd post mine here, but like Fermant's Last Theorem, which couldn't fit in the page margin, there's not enough room on the Internet for mine... Les
|
By Charles R Hankey - 2/13/2010
Hey Les -
One of the things I've always liked about our profession is that it is sometimes just as educational to prove one's self wrong as to prove one's self right.
The pudding is in the proof !
|
By Trent L. Taylor - 2/14/2010
LOL....glad to know that you do have it figured out though!
|