No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Enhancement / convenience API: clientside DSResponse.getDSRequest()

    Hi Isomorphic,

    I just found myself in a situation where I fetched from a DataSource many times inside a Queue. Every fetch did a count-aggregation and returned 0 or 1 rows.
    If count-field is 1 or less I need to display some warning with the name which is in another field from the result (obviously a field I grouped by).
    But: The way the I build it a count of 0 resulted in no rows. No rows (for which I also should issue a warning) means no other field that I could use for the warning.
    As it was a queue generated from a loop over the selected ListGrid-records I had no access to the request. My solution was to change the DB-View, so that also for a count of 0, a row with count=0 is returned.

    My proposed enhancement is:
    It would have been way easier if I could access the DSRequest from the DSResponse. This way I could have asked the DSRequest for its criteria and display that value in my warning.
    This is not possible currently, but is most likely an easy enhancement as you are already able to connect every DSRequest with its DSResponse in the Developer Console.

    I'm sure there are also other use cases for this and you already added getOperationId() here, which will most likely internally already access the DSRequest.

    Now that I solved my case this has no priority for me, but I think it would be a good enhancement.

    Best regards

    This isn't one we'll plan to do. The DSRequest passed to the framework has many changes made to it - we don't try to preserve your original object intact. We wouldn't want to try to document all the ways in which it gets modified for different code paths, as that's all internal details.

    Beyond this, for some use cases there is no DSRequest at all or it is very partial (eg DataSource.updateCaches()) so it would be difficult to safely use such an API - code that worked for a particular scenario of server contact would break in other scenarios. We wouldn't want to create a fragile / unpredictable API like that.


      OK. Thanks for the fast answer and the explanation.

      Best regards