(ThinkGeo.PostgreSql 12.3.2)
When PostgreSqlFeatureSource.CommitTransaction() returns with TotalFailureCount > 0, the TransactionResultStatus property is still set to Success.
(ThinkGeo.PostgreSql 12.3.2)
When PostgreSqlFeatureSource.CommitTransaction() returns with TotalFailureCount > 0, the TransactionResultStatus property is still set to Success.
Thanks Clemens,
Yes. After you do some operations on the PostgreSqlFeature layer such as delete item, add item, edit item. Some of operations may not able to commit to database. We will return the failure count and failureReasons.
Here is an example how we do in the PostgreSqlFeatureSource class
private void ProcessAddBuffer(Dictionary<string, Feature> addBuffer, TransactionResult result)
{
foreach (Feature feature in addBuffer.Values)
{
try
{
InsertFeature(feature);
result.TotalSuccessCount++;
}
catch (Exception e)
{
result.FailureReasons.Add(feature.Id, e.Message);
result.TotalFailureCount++;
}
}
}
Thanks
Frank
My question is not about TotalFailureCount
(which is set correctly) but about TransactionResultStatus
(which is not).
Classes like ShapeFileFeatureSource
or TabFeatureSource
do set TransactionResultStatus
to Failure
if there is any error. This is inconsistent. Is the PostgreSqlFeatureSource
behaviour supposed to be correct?
Thanks Clemen,
Yes. In the ShapeFileFeatureSource and TabFeatureSource we have some code like this.
if (transactionResult.TotalFailureCount == 0)
{
transactionResult.TransactionResultStatus = TransactionResultStatus.Success;
}
else
{
transactionResult.TransactionResultStatus = TransactionResultStatus.Failure;
}
The PostgreSqlFeatureSource
behavior is different. You could check the transactionResult.TotalFailureCount outside. I will talk with my supervisor see if we real want to keep this consistent with ShapeFileFeatureSource
or TabFeatureSource
.
Thanks
Frank