Closed GoogleCodeExporter closed 8 years ago
Thanks for reporting this issue, we will be looking in to this shortly.
Original comment by apex.es...@gmail.com
on 1 Jun 2010 at 4:59
Fixed in r40 (http://code.google.com/p/force-dot-com-esapi/source/detail?r=40)
insertAsUser and updateAsUser now return the objects they create internally.
This fix should be available form the downloads page in the next release.
For lists we chose to return SaveResult[] and not just a single exception,
because
this way you can get feedback on the specific object that caused the failure.
Also,
you may choose to allow some of them to be inserted/updated even if some are
failing.
With lists you can still use the SaveResult[i].getId() to get the id of the new
object after insertion.
Original comment by apex.es...@gmail.com
on 1 Jun 2010 at 10:04
In the list case, you are forcing the user of your API to have to deal with a
pair of lists (pass both,
iterate over both): the object list they passed into your API and an Id list
they have to build for
themselves from the returned SaveResult list. The poor code this produces
doesn't seem consistent with
your objective "to make it easier for programmers to retrofit security into
existing applications or
build a solid foundation for new development".
It seems that code to support the error case (that would perhaps be better
handled using exceptions)
may be getting in the way of a clean interface for the normal case.
Original comment by keith.clarke.claimvantage@gmail.com
on 4 Jun 2010 at 7:42
In the list case we chose an approach that tries to mimic the "update arr;"
and "Database.insert(arr);" calls as much as possible.
For example, if you call "update arr;" it assumes a "all or none" mode. The
same
thing happens if you call "Database.update(arr, true);" it assumes all or none.
As
long as you are in all or none mode, if one of the objects in the array fails
to
update, none of the updates will be committed and you will get an exception.
Only if
you call "Database.update(arr, false);" then you choose a best effort mode. In
this
case, even if some objects fail, it will not throw an exception. Instead it
will
return an array of SaveResult objects with the results of each update.
The ESAPI library has a similar approach. As long as you use the all or none
mode,
if any of the objects fail to insert/update you should get an exception. Only
if you
are in best effort mode, it will not throw an exception, in which case you can
use
the SaveResult array.
In addition, the ESAPI library also uses the same default as the
Database.insert/update which is all or none mode.
However, the one difference is, when calling "insert arr;" or "Database.insert"
the
array gets populated with the ids that were just created. In our case, because
we
create new objects inside the library, the caller's original objects don't get
populated with those ids. (And we can't just set them in the library because
the ID
field is read only.) We could have returned the new array of objects we use
internally as a return value, but we chose to stick to the
Database.insert/update
approach which was to return the SaveResult array. Especially that the IDs are
also
available from the SaveResult objects.
Having said that, I think this is not the easiest approach for users to work
with
when they need to continue and manipulate the objects they just inserted. We
are
thinking of the best way to implement it in such a way that it will also return
the
new objects with the IDs set, and also the SaveResult array.
Original comment by apex.es...@gmail.com
on 4 Jun 2010 at 10:00
Thanks for the additional consideration of this.
Original comment by keith.clarke.claimvantage@gmail.com
on 5 Jun 2010 at 2:04
Changed the return value of the insertAsUser/updateAsUser/deleteAsUser
functions in r45 (in array mode) to return a special object which can be used
to get info such as the Database.SaveResult[] and the actual objects that were
used to insert/update the db.
This way, we can have the SaveResult info the same way the Database.insert
works with arrays. And at the same time we can return the actual objects that
were used to insert/update the db.
Original comment by apex.es...@gmail.com
on 9 Jun 2010 at 11:18
Original issue reported on code.google.com by
keith.clarke.claimvantage@gmail.com
on 27 May 2010 at 11:42