Tableless BO Mapping


Author
Message
Alex Luyando
Alex Luyando
StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)StrataFrame User (210 reputation)
Group: StrataFrame Users
Posts: 112, Visits: 1.2K
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

________________
_____/ Regards,
____/ al
Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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!
Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
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?



Greg McGuffey
Greg McGuffey
Strategic Support Team Member (3.3K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
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! BigGrin
Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
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.



Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.
Edhy Rijo
E
StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)StrataFrame VIP (4.6K reputation)
Group: StrataFrame Users
Posts: 2.4K, Visits: 23K
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.

Edhy Rijo

Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
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?



Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.
Charles R Hankey
Charles R Hankey
Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)Advanced StrataFrame User (922 reputation)
Group: Forum Members
Posts: 524, Visits: 30K
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 ?

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search