search

FransBouma / Massive

A small, happy, dynamic MicroORM for .NET that will love you forever.
Other
1.8k stars 322 forks source link

A little bug fixing #321

Closed mirshahreza closed 7 years ago

mirshahreza commented 7 years ago

I think this line of code has a bug , because when the identity field is not integer library generates an error:

Massive.Shared.cs , Line : 1081 ((IDictionary<string, object>)toInsert)[this.PrimaryKeyField] = Convert.ToInt32(cmd.ExecuteScalar());

can be change to

((IDictionary<string, object>)toInsert)[this.PrimaryKeyField] = cmd.ExecuteScalar();

Now any type of identity can retrieve to an object.

FransBouma commented 7 years ago

Sorry but that's by design. Identity fields are integers by nature, not objects.

mirshahreza commented 7 years ago

Really? Many times we have uniqueidentifier for primary key field with newid() default so in the c# we have to object or Guid !!!

FransBouma commented 7 years ago

Yes but that's not an identity field. Identity fields are sequenced fields with numerical sequences. Fields which have NewID() or NEWSEQUENTIALID() set as their defaults are just fields which .... have a function set as their default value, similar to fields which have getdate() set as their default.

The problem with NewID() is that you can't read back its value after insert. With NewsequentialID() this is possible but with custom code which isn't in massive. The code you want to change doesn't do any of that, it only obtains the value of the sequence, which is done in sqlserver with SCOPE_IDENTITY() or @@IDENTITY if you are on old versions. Your change doesn't get a newid() value as that's not possible.

mirshahreza commented 7 years ago

Yes this is right. sorry for my mistake .but I forgot you use SCOPE_IDENTITY() or @@identity . Already I am using my own MicroORM that the generated sql statement returns entire record after commit so we can access all database fields with defaults or identity rules.

So I can manage this by the situation.

Thanks