Unnecessary Database Call on NullIdentifier

Unnecessary Database Call on NullIdentifier

Hi Community,

I have noticed with the scaffolding CRUD when you create the 'DETAIL' webscreen the preparation ínvokes the aggregate even if the input parameter is  NullIdentifier when in Create Mode

As this is all on server but still crossing the application to database boundary wouldn't it be faster and less traffic if the scaffolding did not invoke the agreggate when parameter is NullIdentifier.

Or is the invoke required to bind or something I am missing? (Minimize the number of executed queries)


first of all, does it actually go to the database? :)

it could be optimized...

the reason behind it, you don;t need an extra local variable of that entity.

so it's less code for us.


One less variable I get. Does this mean you use the output varaible of the aggregate as a work varaible? I.E you need to change a value and update the entity so you use the aggregates output variable to hold the original values and overwrite with your new ones if the values are NOT coming from a window. I get it but it seems a little problematic if you want to know the original values further on in the process. But I get it.

" does it actually go to the database? " now that is cool...so when you invoke an aggregate you also get logic around it to say dont actually invoke the SQL statement if the key is Null. What if you are searching for null records on non key columns? I am used to generation of code but not generating logic that is interpreted for you...pretty hard to fix if the intreptation is wrong. It would seem to me that if you Invoke/Call/ an aggregate it will call the SQL and you have to then deal with the results/errors/screw ups etc?
And thank you J, I wil try not to bother this forum on implmentation questions like how do I use a popup but these under the cover issues I need to iron out. Would love if you could help me on https://www.outsystems.com/forums/discussion/18990/best-practice/

mind you, these are my assumptions and experiences :)

on the less variable.

1. you can always do a getforupdate<entity> before actual storing/update the record.

2. and you will end up with the listrecord or editrecord value which will be different than the original aggregate if you actully changed it.

and the other

- the optimization goes a long way. if you are showing less attributes in the screen, it will fetch only those attributes instead of the whole record. (in production mode at least)

and in my experience, the interpretation is pretty good :)

if you are searching in the database, you will have a complex where-clause anyways, so chances are it will go to the database anyways.

what i was thinking about "does it actually go to the database" was merely about the aggregrate of the detail-screen, which is  a simple query with a clause on the primary-key.

since PK's cannot be null in outsystems (well it can, but you get my drift) it can easily detect if it wants to go to the database or stay in the code...


on the less variable.
  • I understand how to get around it but I am just saying in other coding paraidgms it would be more conterversial than acceptable to play with the output of 'Fetches/Gets' as they should remain as they are as a result of the Fetch/Get.
and the other
  • Again I am saying it is a little conterversial to bother to go to the database if you know there will never be a record found and that logic I would have thought should be present visually on the flows, instead of maybe (as it is not confirmed) it will back off and not actually invoke the database call even after you specifically asked it to! Shaky ground and will contact Outsystems on this as I would like to know for sure as I really dont want to look like an idot latter on when asked why are you going to the database, surely that is unncessary, surely it is increaing traffic, surely do it once in a while but not part of your patterns!