Inconsistency with Save vs SaveAll for AutoIncrement

ServiceStack.OrmLite
1

I was doing some profiling to see exactly what Save and SaveAll does in different instances (version 6.3) for a class that has an [AutoIncrement] property.

image

image
image859×329 30.2 KB 

public class Airport {
[AutoIncrement]
public int Id {get;set;}
public string Name {get;set;}
}

Note for SaveAll I just had one item in a list to test.

My question is why does the Save method do an extra SELECT for a class with an AutoIncrement Id not set (default int = 0) where the SaveAll immediately inserts?

The SaveAll method works perfectly for a class with AutoIncrement in my opinion as this is more efficient. This logic should be applied to Save.

You know the class has an [AutoIncrement] property and if it’s primary key is default (i.e. not set) you can bypass checking if it exists and do an INSERT straight away.

2

SaveAll works in a batch where it can query multiple existing ids in a single query:

Save still needs a query to detect if the record exists or not.

3

Why does Save need to do that for AutoIncrement Ids though?

If I have an Id int that is set to 0, then you immediately know (by the nature of identity columns) that this can be inserted and can bypass the check to see if it exists.

For non AutoIncrement primary keys, you would indeed need to do the select first to see if it exists.

4

SaveAll batch queried for non-default values, i’ve changed Save to match and avoid the query if the PK has a default value.

1 Like
5

That is great thank you Demis! I’ll keep an eye open for when this is released.

6

FYI this change is available from v6.3.1+ that’s now available on MyGet.

1 Like