Feed back on whether an InsertWithChildren, UpdateWithChildren, Delete and etc. succeeded

[Patrick Lind]

Perhaps this is wrong headed but the way I was using SQLite-Net prior to adding this extensions module was that the Insert, Update and Delete methods from SQLite-Net proper would return an int.

I would then use this int to determine whether or not to commit or rollback data base transactions.

All of the Extensions methods (InsertWithChildren, UpdateWithChildren and etc) are void methods.

Is there a way to get these methods to return an indicator of pass or fail as well? Or am I thinking about this wrong?

[Patrick Lind]

It does look like the source is doing conn.Execute which returns an int. Can we just pass that through? Or was there a reason you wanted to use void?

[Guillermo Gutiérrez]

I see no reason to not implement it as it doesn't break backwards compatibility.

What would you expect it to return on recursive operations?

[Patrick Lind]

Would it make sense to have it return 1 unless an operation fails and then return -1 if something does go awry? The general idea I think for the SQLite-Net returns is to just let you know everything passed or something failed. If even 1 thing fails I am going to rollback and not commit my database change. What do you think?

[Guillermo Gutiérrez]

SQLite-Net usually handles errors by raising exceptions and they are escalated to the caller. Execute method returns the number of affected rows. We could return the accumulative result of all the operations.

What do you think?

[Patrick Lind]

Ohh.. I misunderstood what execute was returning. I thought it would return -1 if something "bad" happened. So really I just need to commit or rollback based on a try catch. But yes for unit testing purposes it would be helpful to return the accumulative result of all the operations. Or... would it make the most sense to return the affected rows of the top most object? Would someone care about number of children rows affected?

[Guillermo Gutiérrez]

I implemented this functionality but I'm not going to publish it. It could make sense to some degree, but it adds a level of complexity to the code and the API that it's not trivial. I realized this when trying to document what it should return on every method. For example, InsertAllWithChildren may return the number of inserted objects, but the operation may also have affected rows in another tables either by inserting recursively or updating foreign keys. At some point it's not even clear what a simple UpdateWithChildren call is going to return.

So... to sum up, I'm going to keep it simple and not implement this.

[Patrick Lind]

Not a problem. It sounds like a pain to implement and in the end I'm getting back less useful information that I originally thought so no problems here.