Łukasz Ledóchowski - Software Developer

Od czasu do czasu musimy wstawić do bazy wiele rekordów naraz, najczęściej w przypadku importu/aktualizacji danych. Jest wiele sposobów na wykonanie tej czynności, ale najprościej stworzyć DbContext, dodać elementy do kolekcji, a następnie zapisać za pomocą SaveChanges. Gdy korzystamy z Entity Framework 6, istnieje kilka zasad, których powinniśmy przestrzegać, aby wydajnośc rozwiązania była przyzwoita: Ustawienie context.Configuration.AutoDetectChangesEnabled na false . Domyślnie Entity Framework używa wykrywacza zmian, aby wygenerować odpowiednie skrypty SQL przy zapisywaniu zmian. Gdy dodajemy rekordy do bazy, to wiemy, że nie ma zmian. Nie ma potrzebu zatrudniania wykrywacza, który w EF 6 zużywa sporo zasobów. Trzeba go wyłączyć. Dzielenie danych na partie. Jeżeli chcemy wstawić do bazy np. 10000 rekordów, lepiej podzielić je na partie i wywoływać SaveChanges() po dodaniu każdej z nich. Jaka powinna być wielkość jednej partii? Może być np. 100, ale to trzeba wydedukować samemu,

From time to time we have to insert a large number of rows into the database, usually because of data import. There are many ways to do it, but the simplest one is to take DbContext, add into the collection, and call SaveChanges. When we use Entity Framework 6 or less, there are a few important rules to follow: Setting context.Configuration.AutoDetectChangesEnabled to false . By default Entity Framework uses change tracker to find all changes made to entities, to generate SQL scripts later. But all we do is make inserts so we know there are no changes, only new rows. There is no need to compare with existing items so change tracker can be disabled. Splitting inserts into batches.  If you want to insert 10000 rows into the database, it is better to split them into small batches and call context.SaveChanges() after every n rows where n should be determined experimentally. 100 isn't bad value, but it depends on the size of data. Recreating DbContext after every batch.  Even if

W ramach mojej działalności gospodarczej tworzę aplikacje przeglądarkowe korzystające z PHP jako backendu i Angular / AgularJS / KnockoutJS / JavaScript do frontendu. Aplikacje te hostowane są na Linuksie, a w domu, na komputerze do pracy, mam Windows 10. Co prawda da się postawić PHP i cały serwer na Windows, ale zawsze miałem wrażenie, że to nie jest dobry pomysł, a różnice w implementacji pewnych rozwiązań mogą mi się później odbić czkawką. Mógłbym też przesiąść się na prywatnym komputerze na Linuksa, ale piszę też w .NET (4.x), więc Windows 10 i tak muszę mieć. Próbowałem przez jakiś czas korzystać z Ubuntu, ale wygoda użytkowania była zdecydowanie niższa niż Windows, co jest tematem na oddzielny wpis. W związku z tym korzystałem z hostingu WPRO na LinuxPL. Zaletą takiego rozwiązania jest brak konieczności zarządzania całym serwerem, łatwe dokonywanie zmian za pomocą panelu DirectAdmin i dostęp przez SSH. Po zalogowaniu przez SSH można bez problemu uruchomić watcha w node, któr

Everyone knows IDisposable interface, right? Right. It is simple. If you use unmanaged resources, you should implement IDisposable and release them when your object is being disposed. Simple. But IDisposable is a very special interface. It even has its own keyword: using . Example use: Code above is equal to: Constructor is called first, then we are doing something inside, and at the end Dispose method is called to finalize work. So maybe we could use IDisposable not only to clean up unmanaged resources, but as a shorter form of try / finally to put our code in specific context. That sounds like a great idea and obviously it is not mine. This idea was used in few places in .NET libraries. Here are 4 examples of IDisposable: First example. This is code from ASP.NET MVC to generate HTML form using Razor: Output of this code will be close to: What happens? Html.BeginForm() is a function that writes "<form>" to response and returns MvcForm type object. MvcF

Today I managed to run AOT compilation in existing Angular 2 application. This is a note to remember what I had to do to make it work: Follow this example: https://medium.com/@laco0416/aot-compilation-with-webpack-359ac9f4916f#.a1v35vlyl Downgrade Typescript to 2.0.10. Downgrade Webpack to 2.1.0-beta.28. Change all "template: require(path)" to "templateUrl: path". Require function is not available in AOT compilation process. Had to add angular2-typescript-loader to handle ts files in webpack (loaders: isProd ? '@ngtools/webpack' : ["awesome-typescript-loader", 'angular2-template-loader']). It handles templateUrl in components. Newest versions of libraries (ts 2.2 and webpack 2.2.0-rc.3) had documented issues with whole mechanism, so I had some fun searching for solutions. Performance before enabling AOT compilation: And after Scripting took 3 seconds less and it is more than visible. Difference is huge. Scripts are now 60

AutoMapper is great library, but it introduces another dependency and requires configuration. I try to stick to convention and use the same names in DTOs and domain objects. That is why I decided to write simple Object extension methods. Usage is simple: There are also some other useful functions: Not a big thing, but I copy this code from one project to another from time to time. And here is source code: