CRUD procedures

Related products: Software Factory Windows GUI Indicium Service Tier

If I have a lot of details in one screen, I mainly use grids instead of grid and form. But if I want to add a record I have to use add in grid or make a task to add a record. It would be really nice to have generated CRUD tasks, this would prevent modelling the same thing multiple times.

Hey Jop, I'd like to propose to take your idea a step further. When you have made these C(r)UD tasks, I think you should be able to connect them to the existing add/delete/update buttons in the toolribbon. Otherwise you'd have to disable those buttons and add an extra set of buttons in the task area.

I think this'd be really cool. You could for instance develop a delete task that performs some kind of cascade-delete, where child records are also being deleted.


Very interesting suggestions. It would be like having instead-of-tasks for inserts, updates and deletes. Form buttons and shortcut keys would work too.



I'm curious about your opinion on these questions:



a) How do process flows tie into this? Do they still recognize instead-of-tasks as actual tasks?

b) What if an instead-of-task is also a drag-drop task? What if it's asynchronous? Could we do reports as well?

c) There's potential for conflicts between authorization for instead-of-tasks and for CRUD operations. Do we keep them synchronized somehow? Or maybe take the greatest common denominator? How about context vs. layout stored procedures?

d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?




a. I think they should look at the instead-of-tasks

b. drag/drop and asynchronicity (is that a word?) must be disabled, i think. Reports would be weird as well.

c. Layout and context procedures should ideally not be a different thing. Why not one big layout/context procedure concept?

d. Yeah, why not?



You could also implement add/update/delete as a procedure by default and have the possibility to weave in additional bits of code template or replace the default insert/update/delete template altogether.
My personal preference is that CRUD works as normal, the only difference being that a stored procedure is called instead of an insert/update/delete statement. This ignores all the 'task'-ness of such stored procedures. Easy to implement, almost zero cognitive overhead, no duplication of code in application logic procedures, almost no extra testing, no extra documentation to write and maintain, no extra training required, etcetera etcetera. It's transparent, and it's cheap.



Henk, to me it is just this. Have procedures handle inserts/updates/deletes instead of direct database interactions. And aditionnaly, be able to add your own code before/after/instead of the default code provided by the tooling.



So not this:

code:
insert into table tablename (col1, col2) 
values (value1, value2)


but this:

code:
exec insert_tablename value1, value2




This also means you no longer have to grant access to insert/update/delete on a specific table. This in turn makes it much more easy to control what interactions a specific user can do for a specific table. For example, only update or delete data the user is authorised to.
Very interesting suggestions. It would be like having instead-of-tasks for inserts, updates and deletes. Form buttons and shortcut keys would work too.



I'm curious about your opinion on these questions:



a) How do process flows tie into this? Do they still recognize instead-of-tasks as actual tasks?

b) What if an instead-of-task is also a drag-drop task? What if it's asynchronous? Could we do reports as well?

c) There's potential for conflicts between authorization for instead-of-tasks and for CRUD operations. Do we keep them synchronized somehow? Or maybe take the greatest common denominator? How about context vs. layout stored procedures?

d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?


......

I'm curious about your opinion on these questions:

......

d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?
......

d. Yeah, why not?




The short answer is that parameters of such tasks are completely determined by the columns of the subject they're connected to. This makes it harder to use them anywhere else. But agreed, I can imagine use cases in which linking such tasks to other subjects makes sense.



The deeper reason I asked all those questions is that I was trying to assess this looming dichotomy between tasks and regular CRUD. This applies to both application logic and model settings.



Easy example: consider an instead-of-update task. Which default procedure do we use? The subject's default procedure? Or the task's default procedure?



Harder example: we're doing a mass update from Excel. Which rows can we update? Do we:

a) Call the subject's context procedure and check if the instead-of-update task is legal for the Excel row?

b) Call the task's layout procedure and use its 'confirm_button_type' result?

c) Call the subject's layout procedure and use its 'confirm_button_type' result?

d) Combinations of the above?



These examples are far too detailed and technical to require an answer right now. And why should application developers have to worry about those things anyway? It should just work in the most obvious way, with the least amount of cognitive overhead. But, if there are conflicting opinions about what's obvious, things are not that simple.



My personal preference is that CRUD works as normal, the only difference being that a stored procedure is called instead of an insert/update/delete statement. This ignores all the 'task'-ness of such stored procedures. Easy to implement, almost zero cognitive overhead, no duplication of code in application logic procedures, almost no extra testing, no extra documentation to write and maintain, no extra training required, etcetera etcetera. It's transparent, and it's cheap.



So I'm leaving this one out in the open, and I wonder how this idea will further develop.
Modeling the same thing multiple times can already be avoided by using the Dynamic Model and dynamically assigned control procedures in the Software Factory. If we would offer generated CRUD tasks as a standard feature in the SF, then we would also use the Dynamic Model and dynamically assigned control procedures to implement this feature.



With that said, I do think it's a nice idea worth considering.
Very interesting suggestions. It would be like having instead-of-tasks for inserts, updates and deletes. Form buttons and shortcut keys would work too.



I'm curious about your opinion on these questions:



a) How do process flows tie into this? Do they still recognize instead-of-tasks as actual tasks?

b) What if an instead-of-task is also a drag-drop task? What if it's asynchronous? Could we do reports as well?

c) There's potential for conflicts between authorization for instead-of-tasks and for CRUD operations. Do we keep them synchronized somehow? Or maybe take the greatest common denominator? How about context vs. layout stored procedures?

d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?




I think it would be nice if they behave as normal tasks for as much as possible. Just generated ones. Synchronizing them with CRUD operations would be a nice touch, but not a must have I think. Also I would enable them to be linked to other subjects, also for using with drag and drop, but I don't have a specific use case for that now.

For reference: 

 


To emphasize the need for this feature I would like to show the following example taken from IAM in Universal:

 

This is very confusing in an end users perspective. Can you tell me the difference between de garbage bins? Or the edit pens? Users should (must) not see this kind of constructions.


Updated idea status OpenOn the backlog

We use also grid only in details. I woud be happy if I just could open the form in a popup.


The following idea has been merged into this idea:

All the votes have been transferred into this idea.

@Jasper We're eagerly looking forward to this functionality! The Idea is scoped in your Release Plan 2021.3 blog, can we indeed expect this functionality with the upcoming platform release 2021.3 as planned?


Unfortunately we haven't got around to this feature yet. It is still high on our backlog, but we don't have an expected date for it at this time.


The following idea has been merged into this idea:

All the votes have been transferred into this idea.

In the 2022.2 we plan to focus on handling insert/update/delete through logic (procedures). 
 
Updated idea status: On the backlogPlanned

Updated idea statusPlannedWorking on it!

Updated idea status Working on it!Next release


From 2022.2, it will be possible to utilize so-called Handlers. These Handler procedures will fully replace the Add, Edit or Delete action once used.

This logic concept can be used best for actions that need to be performed row-by-row, for instance, to delete child records before deleting a parent record. For set-based actions, it is best to use triggers.

These procedures are atomic by default, which means all code run by these procedures is run inside a transaction. This ensures that all mutations made by the procedures will be either run successfully in their entirety or fail and be rolled back to their original state. Just like with Tasks, there is space to weave in templates inside the catch part of the procedure.

Like other logic concepts, you can activate the handler logic per table and action (menu User interface > Subjects > tab Default > tab Settings > tab Performance):

Image

 

In Functionality (menu Business logic), control procedures can use the code group HANDLERS to assign templates to the actions:

Image

Assign code group HANDLERS to the control procedure

 

Image

Assign a template to the program objects

As result, in this example, three procedures are created for the GUI to be used when the GUI actions are executed:

Image


Updated idea statusNext releaseCompleted

Updated idea statusNext releaseCompleted

Whoohoo!!