By Luis Paulo Soares on 9 Apr 2015
Does not throw exception if Id not found. return empty record instead.
J.9 Apr 2015
you can wrap it yourself.
so what would be the advantage of implementing it by OutSystems?

Hélio Dolores9 Apr 2015
That change would be a breaking change with high impact on the current installations.
But...  as S&W said, you can always do it by yourself :)
Kilian Hekhuis10 Apr 2015
Perhaps an extra parameter that defaults to the current operation?
Kilian Hekhuis10 Apr 2015
Instead of wrapping, a Simple Query (platform 8) or Aggregate (platform 9) is also possible, of course.
Yes but then you have to do that for every table? makes no sense at all. The idea is to avoid that.
If we think like that, then we dont need the getEntity action because you can do it throw simple querys? you cant also use a simple query as function or inside expressions and the getEntity action you can. You have to check everytime if the id is empty before do the getentity. but then you have to do that everytime you want to use the get action or else it will throw a exception.

Anyway it was just a idea/suggestion. If its not possible or have high impact then you can close this thread.

Justin James10 Apr 2015
There are three reasons to use GetEntity over a simple query/aggregate:

1. GetEntity is marked as a function, so you can use it inline with parameters. I do NOT consider this a good practice, it makes it harder to read/understand the workflow and understand where data is coming from, and it discourages validation.

2. You want GetEntity to throw an Exception if the record cannot be found, because you prefer that to checking the results of a query. I discourage this as well, since I prefer to not throw exceptions for things that could have been validated in advance. But this is definitely a "fail fast, fail hard" situation and you will find a bug in your code much more quickly like this than with a simple query/aggregate returning an empty record.

3. It's slightly easier to use GetEntity than make that simple query or aggregate.

I like the idea of making the behavior an optional parameter. It doesn't break existing code, and it makes it easier to enable the above scenarios than a simple query/aggregate.