اشتراکها
معرفی Dev Home
اشتراکها
Ninject برای Xamarin
روش بهینه سازی شده تنظیم پایگاه داده در نسخه ۲.۱.۰
Database Initializer
Database
Initializer همانطور که از نامش پیداست، به شما کمک میکند پایگاه داده
پَرباد را به هر صورتیکه در نظر دارید راه اندازی کنید.
هدف از افزودن Database Initializer ها
از آنجایی که Entity Framework، پایگاههای داده زیادی را پشتیبانی میکند و
هر کدام از آنها دارای شرایط، ویژگیها و محدودیت های خاص خود
هستند، شما
میتوانید پایگاه داده مورد نظر خود را آنطور که در نظر دارید ایجاد کنید.
برای مثال پایگاه داده Sqlite طبق اعلام خود تیم Entity Framework دارای
محدودیتهایی برای Migration است. به همین دلیل این پایگاه داده
را نمیتوان مانند SQL Server به راحتی Migrate کرد.
مواردی که توسط Database Initializerها قابل استفاده هستند شامل:
- Create Database
- Delete Database
- Migrate Database
- Seed Database
نمونه مثال جهت تنظیم پایگاه داده به روش جدید:
services.AddParbad() .ConfigureDatabase(builder => { // Choose your database provider (SQL Server, MySql, Sqlite, etc.) builder.Use.... }) .ConfigureDatabaseInitializer(builder => { builder.UseInitializer(async context => { await context.Database.EnsureDeletedAsync(); // OR await context.Database.EnsureCreatedAsync(); // OR await context.Database.MigrateAsync(); }); });
در مثال بالا ابتدا در متد ConfigureDatabase نوع پایگاه داده مورد نظر خود را مشخص میکنیم.
سپس
در متد ConfigureDatabaseInitializer تعیین میکنیم که پایگاه داده به چه
صورتی باید ایجاد شود. همانطور که مشاهده میکنید، شما میتوانید پایگاه
داده را حذف، ایجاد و یا Migrate کنید.
همچنین جهت نوشتن راحتتر تنظیمات، متدهایی برای ایجاد، حذف و Migrate محیا شده که میتوانید مانند زیر از آنها استفاده کنید:
services.AddParbad() .ConfigureDatabase(builder => { // Choose your Entity Framework provider (SQL Server, MySql, Sqlite, etc.) builder.Use.... }) .ConfigureDatabaseInitializer(builder => { builder.CreateDatabase(); // OR builder.DeleteAndCreateDatabase(); // OR builder.CreateAndMigrateDatabase(); });
نکته ۱: اگر هیچکدام از متدهای کمکی بالا برای شما مناسب نیستند، از همان روش اول یعنی UseInitializer استفاده کنید.
نکته ۲: Database Initializer ها، به همان ترتیبی که اضافه شدهاند، اجرا خواهند شد.
نکته ۳:
جهت سادگی در Migrate کردن پایگاه داده، در هنگام تنظیم پایگاه داده مورد
نظر خود میتوانید از متد UseParbadMigrations استفاده کنید.
مثال:
services.AddParbad() .ConfigureDatabase(builder => { // SQL Server builder.UseSqlServer("Connection String", options => options.UseParbadMigrations()); }) .ConfigureDatabaseInitializer(builder => { builder.CreateAndMigrateDatabase(); });
متد UseParbadMigrations معادل متد زیر است:
builder.UseSqlServer("Connection String", options => options.MigrationsAssembly("Parbad"));
نمونه مثالها را همچنین میتوانید در صفحه GitHub پروژه مشاهده کنید.
اشتراکها
سایت reddit و استفاده از Typescript
از نوع دادهای decimal در SQL Server، بیشتر برای انجام کارهای تجاری و ذخیرهی قیمتها و مبالغ استفاده میشود؛ جائیکه اعداد و ارقام خیلی سریع بزرگ میشوند و گاهی از اوقات ممکن است به همراه اعشار هم باشد. اما ... کار با آنها در SQL Server نیازمند نکات ویژهای است که اگر ندید گرفته شوند، محاسبات نادرستی را سبب خواهند شد!
مفهوم تعریف نوع decimal پیشفرض در SQL Server
فرض کنید از EF پیش از EF Core استفاده میکنید که به صورت پیشفرض، نوع System.Decimal را در مدلهای شما به همان decimal در SQL Server نگاشت میکند. فکر میکنید در این حالت خروجی کوئریهای زیر چه چیزی خواهد بود؟
این خروجی را در تصویر ذیل مشاهده میکنید. در اینجا خصوصا به مورد صفر دقت کنید:
علت اینجا است که از دیدگاه SQL Server، نوع decimal پیشفرض، دقیقا به معنای decimal(18,0) است که به آرگومان اول آن، precision و به آرگومان دوم آن، scale میگویند. یعنی حداکثر چه تعداد رقم دسیمال، پیش از ممیز و چه تعداد عدد دسیمال، پس از ممیز قرار است در این نوع داده ذخیره شوند.
بنابراین باتوجه به اینکه در حالت پیشفرض، مقدار scale و یا همان تعداد ارقام مجاز پس از ممیز، صفر است، عدد ارائه شده، به نزدیکترین عدد صحیح ممکن، گرد خواهد شد.
به همین جهت برای رفع این مشکل، باید دقیقا مشخص کرد که scale نوع دادهای decimal مدنظر چیست. برای مثال میتوان از decimal(10,4) استفاده کرد که در اینجا، نتایج صحیحی را ارائه میدهد:
همچنین به عنوان تمرین، مثال زیر را حل کنید!
بنابراین باید بهخاطر داشت، اگر از EF 6x (پیش از EF Core) استفاده میشود، حتما نیاز است مقادیر precision و scale را دقیقا مشخص کنیم؛ وگرنه حالت پیشفرض آن decimal(18,0) است:
رفتار EF Core با نوع دادهای decimal
رفتار EF Core با نوع دادهای decimal بهبود یافته و حالت پیشفرض آن، بدون هیچگونه تنظیمی، نگاشت به decimal(18,2) است. به علاوه اگر این پیشفرض را هم تغییر ندهیم، در حین اعمال Migration، پیام اخطاری را نمایش میدهد:
اگر میخواهید دیگر این اخطار نمایش داده نشود، میتوان از EF Core 6x به بعد، به صورت زیر و سراسری، تنظیم زیر را اعمال کرد:
و یا روش دیگر تنظیم آن، استفاده از ویژگی جدید [Precision(18, 2)] است که میتوان آنها را بر روی خواص decimal قرار داد. اگر از نگارشهای پیشاز EF Core 6x استفاده میکنید، میتوان از ویژگی [Column(TypeName = "decimal(5, 2)")] نیز استفاده کرد.
دو مطلب مرتبط
- از نوعهای دادهای float و یا double در مدلهای EF خود استفاده نکنید.
- همیشه مراقب بزرگ شدن اعداد و مبالغ و جمع نهایی آنها باشید!
مفهوم تعریف نوع decimal پیشفرض در SQL Server
فرض کنید از EF پیش از EF Core استفاده میکنید که به صورت پیشفرض، نوع System.Decimal را در مدلهای شما به همان decimal در SQL Server نگاشت میکند. فکر میکنید در این حالت خروجی کوئریهای زیر چه چیزی خواهد بود؟
select '0.4400' as Expected , cast(0.4400 as decimal) as Actual select '1.3200' as Expected, cast(1.3200 as decimal) as Actual select '1.7600' as Expected, cast(1.7600 as decimal) as Actual select '65.0000' as Expected, cast(65.0000 as decimal) as Actual select '99.50' as Expected, cast(99.50 as decimal) as Actual
این خروجی را در تصویر ذیل مشاهده میکنید. در اینجا خصوصا به مورد صفر دقت کنید:
علت اینجا است که از دیدگاه SQL Server، نوع decimal پیشفرض، دقیقا به معنای decimal(18,0) است که به آرگومان اول آن، precision و به آرگومان دوم آن، scale میگویند. یعنی حداکثر چه تعداد رقم دسیمال، پیش از ممیز و چه تعداد عدد دسیمال، پس از ممیز قرار است در این نوع داده ذخیره شوند.
بنابراین باتوجه به اینکه در حالت پیشفرض، مقدار scale و یا همان تعداد ارقام مجاز پس از ممیز، صفر است، عدد ارائه شده، به نزدیکترین عدد صحیح ممکن، گرد خواهد شد.
به همین جهت برای رفع این مشکل، باید دقیقا مشخص کرد که scale نوع دادهای decimal مدنظر چیست. برای مثال میتوان از decimal(10,4) استفاده کرد که در اینجا، نتایج صحیحی را ارائه میدهد:
همچنین به عنوان تمرین، مثال زیر را حل کنید!
select iif(cast(0.1 + 0.2 as decimal) = 0, 'true', 'false')
بنابراین باید بهخاطر داشت، اگر از EF 6x (پیش از EF Core) استفاده میشود، حتما نیاز است مقادیر precision و scale را دقیقا مشخص کنیم؛ وگرنه حالت پیشفرض آن decimal(18,0) است:
modelBuilder.Properties<decimal>().Configure(x => x.HasPrecision(18, 6));
رفتار EF Core با نوع دادهای decimal
رفتار EF Core با نوع دادهای decimal بهبود یافته و حالت پیشفرض آن، بدون هیچگونه تنظیمی، نگاشت به decimal(18,2) است. به علاوه اگر این پیشفرض را هم تغییر ندهیم، در حین اعمال Migration، پیام اخطاری را نمایش میدهد:
No store type was specified for the decimal property 'Price' on entity type 'Product'. This will cause values to be silently truncated if they do not fit in the default precision and scale. Explicitly specify the SQL server column type that can accommodate all the values in 'OnModelCreating' using 'HasColumnType', specify precision and scale using 'HasPrecision', or configure a value converter using 'HasConversion'.
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder) { configurationBuilder.Properties<decimal>().HavePrecision(18, 6); }
دو مطلب مرتبط
- از نوعهای دادهای float و یا double در مدلهای EF خود استفاده نکنید.
- همیشه مراقب بزرگ شدن اعداد و مبالغ و جمع نهایی آنها باشید!
اشتراکها
BenchmarkDotNet v0.10.13 منتشر شد
BenchmarkDotNet v0.10.13 has been released! This release includes:
- Mono Support for DisassemblyDiagnoser: Now you can easily get an assembly listing not only on .NET Framework/.NET Core, but also on Mono. It works on Linux, macOS, and Windows (Windows requires installed cygwin with
obj
andas
). (See #541) - Support ANY CoreFX and CoreCLR builds: BenchmarkDotNet allows the users to run their benchmarks against ANY CoreCLR and CoreFX builds. You can compare your local build vs MyGet feed or Debug vs Release or one version vs another. (See #651)
- C# 7.2 support (See #643)
- .NET 4.7.1 support (See 28aa94)
- Support Visual Basic project files (.vbroj) targeting .NET Core (See #626)
- DisassemblyDiagnoser now supports generic types (See #640)
- Now it's possible to benchmark both Mono and .NET Core from the same app (See #653)
- Many bug fixes (See details below)
اشتراکها