1

Topic: EF + different DBMS in one project: a migration question

In one project some DBMS is used. It is required to add migration least  a method. I.e. for each DBMS there will be files Migrations. It is possible to specify folder Migrations in DbMigrationsConfiguration, but there are problems (all the same searches for a file from another's DBMS). How it is better to make, at usage EF?

2

Re: EF + different DBMS in one project: a migration question

S> In one project some DBMS is used. It is required to add migration least  a method. I.e. for each DBMS there will be files Migrations. S> It is possible to specify folder Migrations in DbMigrationsConfiguration, but there are problems (all the same searches for a file from another's DBMS). S> As it is better to make, at usage EF? At you for each basis the DbContext, for each of them you create own DbMigration, in what a problem? Other accessible variant - Database Projects, but there it is necessary to look: there are restrictions which it is visible only in a usage time

3

Re: EF + different DBMS in one project: a migration question

Now understood, apparently, in what a problem, but  people so do?! Would do for everyone DBContext the own project - there would be no problems...

4

Re: EF + different DBMS in one project: a migration question

Hello, Shmj, you wrote: S> In one project some DBMS is used. It is required to add migration least  a method. I.e. for each DBMS there will be files Migrations. S> It is possible to specify folder Migrations in DbMigrationsConfiguration, but there are problems (all the same searches for a file from another's DBMS). S> As it is better to make, at usage EF? Without specifying version EF you risk seriously to overshoot with the decision. For itself for a long time selected https://fluentmigrator.github.io/articl … rface.html it is not anchored to ORM and do that that is necessary, instead of dance round ideological correctness of any decision. With different DBMS here: https://fluentmigrator.github.io/articl … pport.html

5

Re: EF + different DBMS in one project: a migration question

Hello, Danchik, you wrote: D> without specifying version EF you risk seriously to overshoot with the decision. D> for itself for a long time selected https://fluentmigrator.github.io/articl … rface.html D> it is not anchored to ORM and do that that is necessary, instead of dance round ideological correctness of any decision. D> with different DBMS here: https://fluentmigrator.github.io/articl … pport.html I Support. Fluent Migrator it is good. Unix way - the separate task separate , well works both for small projects, and for an enterprise (there is a preview for  DBA for example), is  for everyones  or  systems.

6

Re: EF + different DBMS in one project: a migration question

D>> without specifying version EF you risk seriously to overshoot with the decision. D>> for itself for a long time selected https://fluentmigrator.github.io/articl … rface.html D>> it is not anchored to ORM and do that that is necessary, instead of dance round ideological correctness of any decision. D>> with different DBMS here: https://fluentmigrator.github.io/articl … pport.html bnk> I Support. Fluent Migrator it is good. Unix way - the separate task separate , well works both for small projects, and for an enterprise (there is a preview for  DBA for example), is  for everyones  or  systems. In sense... Than it is good? What it is necessary most to write all hands in vim? Or there it is possible automatically  diff sql script from changes in a database?

7

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: D>>> without specifying version EF you risk seriously to overshoot with the decision. D>>> for itself for a long time selected https://fluentmigrator.github.io/articl … rface.html D>>> it is not anchored to ORM and do that that is necessary, instead of dance round ideological correctness of any decision. D>>> with different DBMS here: https://fluentmigrator.github.io/articl … pport.html bnk>> I Support. Fluent Migrator it is good. Unix way - the separate task separate , well works both for small projects, and for an enterprise (there is a preview for  DBA for example), is  for everyones  or  systems. T> in sense... Than it is good? What it is necessary most to write all hands in vim? Aha. Those that need to write all hands (not is mandatory directly on SQL, for compatibility with different bases), but hands. Some other pluses already enumerated. If in the project the basis begins  through generation diff scripts, long such project normally does not live...

8

Re: EF + different DBMS in one project: a migration question

T>> in sense... Than it is good? What it is necessary most to write all hands in vim? bnk> Aha. Those that need to write all hands (not is mandatory directly on SQL, for compatibility with different bases), but hands. bnk> some other pluses already enumerated. bnk> If in the project the basis begins  through generation diff scripts, long such project normally does not live... It is simply interesting to me: you sometime that or more or less difficult on PL-SQL or T-SQL did? And how you all similar on FluentMigrator can ?

9

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: bnk>> If in the project the basis begins  through generation diff scripts, long such project normally does not live... T> it is simply interesting to me: you sometime that or more or less difficult on PL-SQL or T-SQL did? You doubt my competence? T> and how you all similar on FluentMigrator can ? As well as on normal SQL. You receive type system linq, but oriented on operation with meta data. It is more convenient, than normal SQL if it is necessary to support more than one type of bases for example, but near to it left. At me experience such that if programmers is required something of type diff to write a basis upgrade, it means that they do not supervise changes and basis structure actually, and here it already a sign  a small animal.

10

Re: EF + different DBMS in one project: a migration question

T>> and how you all similar on FluentMigrator can ? bnk> As well as on normal SQL. You receive type system linq, but oriented on operation with meta data. It is more convenient, than normal SQL if it is necessary to support more than one type of bases for example, but near to it left. bnk> at me experience such that if programmers is required something of type diff to write a basis upgrade, it means that they do not supervise changes and basis structure actually, and here it already a sign  a small animal. I to that if at you a heap of any stored procedures, the user functions etc. any linq - similar syntax does not help you CREATE PROCEDURE Production.usp_UpdateInventory @OrderDate datetime AS MERGE Production. ProductInventory AS target USING (SELECT ProductID, SUM (OrderQty) FROM Sales. SalesOrderDetail AS sod JOIN Sales. SalesOrderHeader AS soh ON sod. SalesOrderID = soh. SalesOrderID AND soh. OrderDate = @OrderDate GROUP BY ProductID) AS source (ProductID, OrderQty) ON (target. ProductID = source. ProductID) WHEN MATCHED AND target. Quantity - source. OrderQty <= 0 THEN DELETE WHEN MATCHED THEN UPDATE SET target. Quantity = target. Quantity - source. OrderQty, target. ModifiedDate = GETDATE () OUTPUT $action, Inserted. ProductID, Inserted. Quantity, Inserted. ModifiedDate, Deleted. ProductID, Deleted. Quantity, Deleted. ModifiedDate; GO it is admissible, there is such stored procedure how you are going to use linq syntax?

11

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: T> it is admissible, there is such stored procedure how you are going to use linq syntax? Yes in any way - so the text also goes In one current project on FluentMigrator for  it looks approximately so: [Migration (201808016516)] class ReasonWhyWeChangeUpdateInventory: Migration {void Up () {Execute. Sql (StoredProcedure. UpdateInventory. Drop); Execute. Sql (StoredProcedure. UpdateInventory. V5);} void Down () {Execute. Sql (StoredProcedure. UpdateInventory. Drop); Execute. Sql (StoredProcedure. UpdateInventory. V4);}} It is possible is better?

12

Re: EF + different DBMS in one project: a migration question

T>> it is admissible, there is such stored procedure how you are going to use linq syntax? bnk> yes in any way - so the text also goes bnk> In one current project on FluentMigrator for  it looks approximately so: bnk> bnk> [Migration (201808016516)] bnk> class ReasonWhyWeChangeUpdateInventory: Migration bnk> {bnk> void Up () bnk> {bnk> Execute. Sql (StoredProcedure. UpdateInventory. Drop); bnk> Execute. Sql (StoredProcedure. UpdateInventory. V5); bnk>} bnk> void Down () bnk> {bnk> Execute. Sql (StoredProcedure. UpdateInventory. Drop); bnk> Execute. Sql (StoredProcedure. UpdateInventory. V4); bnk>} bnk>} bnk> bnk> It is possible is better? And now present that such sp - under 150 pieces that at you such "StoredProcedure. UpdateInventory. V5" and than it differs from "StoredProcedure. UpdateInventory. V4", it string? And you drag all these old versions behind yourself? Better  all it , you did not work with Database projects or Red-Gate DLM? Idea Up and Down is quite good, whether but so it is necessary to roll away back? I not to time such did not see, that it was necessary, enough and that it was possible to go only forward...

13

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: T>>> and how you all similar on FluentMigrator can ? T> I to that if at you a heap of any stored procedures, the user functions etc. any linq - similar syntax does not help you T> T> CREATE PROCEDURE Production.usp_UpdateInventory T> @OrderDate datetime T> AS T> MERGE Production. ProductInventory AS target T> USING (SELECT ProductID, SUM (OrderQty) FROM Sales. SalesOrderDetail AS sod T> JOIN Sales. SalesOrderHeader AS soh T> ON sod. SalesOrderID = soh. SalesOrderID T> AND soh. OrderDate = @OrderDate T> GROUP BY ProductID) AS source (ProductID, OrderQty) T> ON (target. ProductID = source. ProductID) T> WHEN MATCHED AND target. Quantity - source. OrderQty <= 0 T> THEN DELETE T> WHEN MATCHED T> THEN UPDATE SET target. Quantity = target. Quantity - source. OrderQty, T> target. ModifiedDate = GETDATE () T> OUTPUT $action, Inserted. ProductID, Inserted. Quantity, T> Inserted. ModifiedDate, Deleted. ProductID, T> Deleted. Quantity, Deleted. ModifiedDate; T> GO T> T> it is admissible, there is such stored procedure how you are going to use linq syntax? Here, the pancake, caught. In any way time I will not find in linq2db to fasten output to  and another DML to the operations, most it is necessary. With linq2db to me these all  , simply are not necessary. And you what for? And syntax here it: https://linq2db.github.io/articles/sql/ … e-API.html

14

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: T> and now present that such sp - under 150 pieces that at you such "StoredProcedure. UpdateInventory. V5" and than it differs from "StoredProcedure. UpdateInventory. V4", it string? It is a file, but as a matter of fact yes, it is possible to tell that string. Yes, such files there can be hundreds, it of anything. But the it is less  and functions - the better. We perceive them as inevitable harm. T> and all these old versions you drag behind yourself? Aha. T> it is better  all , you did not work with Database projects or Red-Gate DLM? It is not assured, how Database Project helps in  migrations? DLM - unless not the same that FluentMigrator, but for money and with support of all one type target bases (that is, without fluent syntax)? You suggest to change all directly in basis of the developer hands, then  a difference, and to apply changes? Or? If so AFAIK, it is the bad variant, unsuitable. Control loss over basis as a matter of fact. The fur small animal, it creeps imperceptibly. IMHO, it is better to force than developers to write an upgrade hands that they thought of how the existing data and that it is all will be updated it was possible to understand and trace easily - that is, all changes  in the monitoring system of versions, and they are read and . The generated scripts in this plan - a sediment. Yes, I consider the scenario when all user data it is necessary to save, delete them is inadmissible. T> idea Up and Down is quite good, whether but so it is necessary to roll away back? I not to time such did not see, that it was necessary, enough and that it was possible to go only forward. However, it meets. Infrequently, but it is better that it was, than that was not.

15

Re: EF + different DBMS in one project: a migration question

Hello, Danchik, you wrote: D> Here, the pancake, caught. In any way time I will not find in linq2db to fasten output to  and another DML to the operations, most it is necessary. With linq2db to me these all  , simply are not necessary. And you what for? D> And syntax here it: https://linq2db.github.io/articles/sql/ … e-API.html If the logic of security arrangement is (for example implemented at basis level (quite real situation, unfortunately) codeless in basis AFAIK it is difficult to manage. Type if the user - Vasja, and the Oriental cherry already blossomed, we return it one list on select * from view_customers, and if Petja - that other list. Clearly that in this case to a straight line select * from customers for the majority mortal generally it is forbidden.

16

Re: EF + different DBMS in one project: a migration question

About files I did not understand: if there is a monitoring system of versions it is enough of what the stored procedure is present at the monitoring system of versions once, or not? If you drag all versions behind yourself in the code, as a matter of fact, you are somewhere before invention SVN I did not work with database projects, but in my opinion there just philosophy in synchronizing basis by generation of a script within the limits of IncrementalUpgrade that in difference generation not so? At the moment of any check-in in the monitoring system of versions you see a difference which turned out in the form of a script clear to all who works with bases, what here not so? This project which generates a difference, is a part solution, therefore always it is possible to trace, who changed the circuit and why besides, the user code which is necessary on the new circuit of basis, is together with scripts which change basis, with FluentMigraor the application code lives in your case separately and the code of change of basis lives separately - as you guarantee, what there will be no error of the coordination of changes so the one who does GetLatests, receives really working, as well as is expected the code? When you do not need to have rollback possibility, and you write the code in Down (), you as a matter of fact do operation which nobody estimates, i.e. waste time of Migratsiii in EF Code-First to me personally more clearly, than by means of FluentMigrator: in EF you change types,  by means of the built in possibilities visual studio automatically a difference in the form of migrations, have possibility to turn unsupported modern tooling sql operations in extension methods, i.e. You have support of the environment for the same result which turns out by , and, means, subject to approach errors in FluentMigrator and the most important difference EF Code-First Migrations from FluentMigrator: the code of change of basis lives nearby if not together with the application code, i.e. synchronization of application with the basis circuit is guaranteed for any moment of time using FluentMigrator; namespace FluentMigrator_sample. Migrations {[Migration (2014110601)] public class Migration2014110601: Migration {public override void Up () {Create. Table ("Users").WithColumn ("ID").AsInt32 ().PrimaryKey ().WithColumn ("Name").AsString ();} public override void Down () {Delete. Table ("Users");}}} as in FluentMigrator it is guaranteed, what the column in Dto, actually, is called "ID", instead of "Id"? There, where I see by hand written string's, I automatically have a question: "in what year of 20 centuries I am"?

17

Re: EF + different DBMS in one project: a migration question

D> With linq2db to me these all  , simply are not necessary. And you what for? You think, what I would not like, that stored procedures in amounts over 300, at all would not be? Not all so carries, as to you

18

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: [Skip] T> as in FluentMigrator it is guaranteed, what the column in Dto, actually, is called "ID", instead of "Id"? There, where I see by hand written string's, I automatically have a question: "in what year of 20 centuries I am"? And unless EF Migrations on another work? The same lines, and also all is necessary accurately .

19

Re: EF + different DBMS in one project: a migration question

D> [Skip] T>> as in FluentMigrator it is guaranteed, what the column in Dto, actually, is called "ID", instead of "Id"? There, where I see by hand written string's, I automatically have a question: "in what year of 20 centuries I am"? D> And unless EF Migrations on another work? The same lines, and also all is necessary accurately . To it also is called "Code-First" that in the beginning you change the model: titles of properties, for example, then you generate migration - for you it is done automatically by a development environment, with FluentMigration how much I understood, all on the contrary - you hands write in the beginning migration, then change basis, then by hands do mapping properties of a class that was set in the very first migration, more shortly, three times it is more than operation, and result (if anywhere it is casual not o) - the same

20

Re: EF + different DBMS in one project: a migration question

Hello, takTak, you wrote: D>> [Skip] T>>> as in FluentMigrator it is guaranteed, what the column in Dto, actually, is called "ID", instead of "Id"? There, where I see by hand written string's, I automatically have a question:" In what year of 20 centuries I am "? D>> And unless EF Migrations on another work? The same lines, and also all is necessary accurately . T> to it also is called"Code-First"that in the beginning you change the model: titles of properties, for example, then you generate migration - for you it is done automatically by a development environment, will not speak why Code-First feeblly withstands criticism, in general it is not my way. T> with FluentMigration how much I understood, all on the contrary - you hands write in the beginning migration, then change basis, then by hands do mapping properties of a class that was set in the very first migration, more shortly, three times it is more than operation, and result (if anywhere it is casual not o) - the same Do migration, and do, as there at you, Scaffolding. That that it is far from perfect, the same merit EF emphasized on Code-First. And that that you with EF piled   - all the same  libraries and  them to architecture. Perhaps when the hand will be pulled to write new  procedure, recall this project https://github.com/linq2db/linq2db.EntityFrameworkCore. We just search for the active users, I promise defects  with speed of a bullet.