List.Contains problem

May 10, 2016 at 5:43 PM
I came across this problem and I must be missing something or this is a little bug, check this sample code
var a = uow.NewEntity<entity_object>();
var b = uow.NewEntity<entity_object>();

var list = new List<entity_object>();

entity_object is a simple IEntity with an int id identity (and I guess the problem sits here).
On new objects the HashCode is the same (0) on all new objects and the contains fails.

Am I wrong ?
May 10, 2016 at 7:54 PM
no, you're right, that's an overlook (bug). Entities are compared for equal as 'primary key equality', not as .NET objects, so entities from different sessions can be detected as equal. In you example, the new objects with identity PK have its PK values 0, so 'a' and 'b' are detected as equal. that happens only in this case (I hope) - new objects with identity PK.
I used to have identity PKs initialized on New with automatic negative value (auto-incremented static field in c#), but then decided it's not needed, so removed it. It turns out this was a wrong step. I will bring it back, so your example will work correctly. Can you live with this for a while, until next push (couple of weeks) ?
May 10, 2016 at 9:20 PM
sure I can wait I just have to work around it in one or two points for now, I still have to integrate latest release and about that do you think is it possible to avoid the creation of the [Vita_ArrayAsTable] type if no stored procedures are used ? In some scenario we can't modifiy the db at all...
May 10, 2016 at 9:33 PM
ArrayAsTable - I think you can skip creating it if you don't use stored procs. But also you can't use list.Contains(value) in LINQ statements. Try it, let me know if it works for you
May 11, 2016 at 10:00 AM
Ok I've checked and I can't remove list.Contains in linq statements :)
I will find a way to address the creation of the ArrayAsTable
May 11, 2016 at 5:30 PM
Ok, wait... I can make it easier for you, I will add a flag in DbSettings that will force the framework to do list.Contains the old way, without array type but by embedding literal lists. .
I think your case is important as an example of a legacy, pre-existing stuff, so I think it is important to make VITA adaptable to situations like these.
Give me time until end of week, I will push a bunch of little fixes and this thing
May 15, 2016 at 5:51 AM
Edited May 15, 2016 at 5:52 AM
Done, added flag DbOptions.ForceArraysAsLiterals - this will allow working without this custom db type
And identity initialization is fixed as well
May 15, 2016 at 9:23 AM
Upgraded to latest version and everything seems to work fine, I will let you know if I find other issues related to this. Thanks man,