I agree Arjan, more often than not a task should be Atomic.
In my project we use Dynamic model code to set all task to Atomic unless they have a tag called 'TASK_NOT_ATOMIC’
update t
set t.single_transaction = 1
from task t
where t.project_id = @project_id
and t.project_vrs_id = @project_vrs_id
and t.task_type_id = 'STORED_PROCEDURE'
and t.single_transaction = 0
and not exists (
select 1
from task_tag tt
where tt.project_id = t.project_id
and tt.project_vrs_id = t.project_vrs_id
and tt.tag_id = 'TASK_NOT_ATOMIC'
and tt.task_id = t.task_id
)
-- Set single transaction (atomic) off when exists as tag.
update t
set t.single_transaction = 0
from task t
where t.project_id = @project_id
and t.project_vrs_id = @project_vrs_id
and t.task_type_id = 'STORED_PROCEDURE'
and t.single_transaction = 1
and exists (
select 1
from task_tag tt
where tt.project_id = t.project_id
and tt.project_vrs_id = t.project_vrs_id
and tt.tag_id = 'TASK_NOT_ATOMIC'
and tt.task_id = t.task_id
)
This should be a project(version) setting in my opinion. For existing projects, defaulting to true could have serious impact, while on new projects you'd want this behaviour by default.
Robert Jan de Nie wrote:
This should be a project(version) setting in my opinion. For existing projects, defaulting to true could have serious impact, while on new projects you'd want this behaviour by default.
I think a validation should be sufficient in those cases. Adding (yet another) option also has a serious impact on making things complex (Current users: Did I had the checkbox enabled? New users: What does this checkbox?). In my experience adding things as ‘options’ is for a short term OK, but add more complexity to the product. Having less is more ;-). I think an upgrade validation should be sufficient in that case.
I agree that less is usually more and a validation will suffice. But people do need to be aware of just implementing everything as an atomic transaction if the application/logic has not been set up this way, or if transaction handling was built in manually before.
Updated idea statusOn the backlog→Planned
@Robert Jan de Nie I don't really get your point, what's the problem with simply having that setting default to TRUE for any new Task that's created after the upgrade to a new Software Factory version if it's the better thing to do?
I'd say, if that's a problem for developers they are failing on 2 important topics:
- Reading Release Notes
- Make a conscious choice about any setting used when creating functionality in the SF
And from a quality process perspective, I'd assume any proper project setup would have some sort of:
- Document Hygiene standards, which you can update after the release (e.g. what default settings / code buildup does the project use, and why)
- Quality review (e.g. a second pair of eyes that reviews all setup done for a given work item)
This setting (even after googling) is quite abstract for Low Code (non-tech) Developers, so I'd prefer the better setting to be the default setting (if in doubt, usually developers don't change a setting).
In the 2022.2 version (which is expected somewhere in june) the ‘Atomic transaction’ checkbox will be checked by default, unless the majority of existing tasks in the project version are not atomic.
Updated idea statusPlanned→Next release
Updated idea statusNext release→Completed