26

Re: That does not suffice in heavy ORM?

A> I about other modularity where Identity Map not inside orm, and nearby, that is objects are tracked not mapper, and by application (a separate subsystem of model). You mean Identity Map not inside Unit Of Work?

27

Re: That does not suffice in heavy ORM?

Hello, igor-booch, you wrote: A>> I about other modularity where Identity Map not inside orm, and nearby, that is objects are tracked not mapper, and by application (a separate subsystem of model). IB> you mean Identity Map not inside Unit Of Work? More likely uow (its functions) not inside orm.

28

Re: That does not suffice in heavy ORM?

Hello, neFormal, you wrote: F> it for uniformity of the code. F> if is dsl through which there is an operation from a DB it be no point to use simultaneously and it, and bare sql. One language is easier. I think, to write a method which calls raw sql easier and cleans  for the given type, than to potter with dsl extension which as a result will do too most.

29

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: F>> if is dsl through which there is an operation from a DB it be no point to use simultaneously and it, and bare sql. One language is easier. A> I think, to write a method which calls raw sql easier and cleans  for the given type, than to potter with dsl extension which as a result will do too most. It already crutches.

30

Re: That does not suffice in heavy ORM?

Hello, neFormal, you wrote: A>> I Think, to write a method which calls raw sql easier and cleans  for the given type, than to potter with dsl extension which as a result will do too most. F> it already crutches. In what? It is possible to write was general-purpose: on type to receive a table name, to generate and fulfill request, to call evict for the given type. And for linq it will and look indistinguishably from the main language.

31

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: A>>> I Think, to write a method which calls raw sql easier and cleans  for the given type, than to potter with dsl extension which as a result will do too most. F>> it already crutches. A> in what? That you for a separate case pass to other language. You put a prop for the logic. A> and for linq it will and look indistinguishably from the main language. If you work at level linq it is normal. In this case you linq expand.

32

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: A> it is strange to demand from orm such functionality: truncate table is ddl which is similar to calls drop table and create table with  indexes, keys and triggers. And ddl in orm should appear only at level of migrations. Temporary tables?

33

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: A> it is difficult to invent application heavy orm outside of simple crud applications, "gravity" becomes useless and starts to hinder. I even would specify. It is difficult to invent application  orm outside of demonstration projects.

34

Re: That does not suffice in heavy ORM?

IT> I even would specify. It is difficult to invent application  orm outside of demonstration projects. Under  you that understand: 1) solidity of architecture, a principle "use all or anything" 2) or presence Identity Map?

35

Re: That does not suffice in heavy ORM?

Hello, igor-booch, you wrote: IB> Under  you that understand: It is a question here the Author: amironov79 Date: 13.11 13:46.

36

Re: That does not suffice in heavy ORM?

Hello, IT, you wrote: IT> Hello, amironov79, you wrote: A>> it is strange to demand from orm such functionality: truncate table is ddl which is similar to calls drop table and create table with  indexes, keys and triggers. And ddl in orm should appear only at level of migrations. IT> temporary tables? Temporary tables as means to avoid truncate, or you ask about necessity to do truncate temporary tables? In the same oracle temporary tables within session (transaction) differ from normal a little, and outside of table session it is possible to clean and without orm. The general-purpose decision all not to receive.

37

Re: That does not suffice in heavy ORM?

Hello, IT, you wrote: A>> it is difficult to invent application heavy orm outside of simple crud applications, "gravity" becomes useless and starts to hinder. IT> I even would specify. It is difficult to invent application  orm outside of demonstration projects. Each time when I reflect on learning and adding of support any ORM, I will come across judgement similar to it All these EF, Hibernate - they that, really such useless in industrial (in the sense, heaped up to horror) systems? I while only looked interiors EF. One and a half years ago. EF6 - fierce . EF.Core like anything (in sense of the internal organization). But it then yet was not  (as well as itself.Net Core/Standard). Therefore decided to wait...

38

Re: That does not suffice in heavy ORM?

Hello, IT, you wrote: IT> Hello, igor-booch, you wrote: IB>> Under  you that understand: IT> It is a question here the Author: amironov79 Date: 13.11 13:46. I, like, already answered it. Both that, and another therefore as I do not know orm with Identity Map which would not be monolithic.

39

Re: That does not suffice in heavy ORM?

Hello, Kovalenko Dmitry, you wrote: IT>> I even would specify. It is difficult to invent application  orm outside of demonstration projects. > Each time when I reflect on learning and adding of support any ORM, I will come across judgement similar to it > All these EF, Hibernate - they that, really such useless in industrial (in the sense, heaped up to horror) systems? They are functional and convenient, but when understand, what mechanisms (which functions often it is necessary also  at themselves in application) there turn, there is a question in  such monsters. If to take any program of data handling, it: 1. Reads the data (query generator, mapper), 2. Changes them (change tracker), 3. Saves changed (query generator, mapper, conflict resolver). For orm I do not see good variants: Or to hold opened session and to occupy basis resources, or twice to find the data and to use the change tracker, or to be engaged in everyones specific  which often solving one problems, create the new.

40

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: >> All these EF, Hibernate - they that, really such useless in industrial (in the sense, heaped up to horror) systems? A> they are functional and convenient, but when understand, what mechanisms (which functions often it is necessary also  at themselves in application) there turn, there is a question in  such monsters. Me monsters  only when they work incorrectly. And so, I the expert in their cultivation A> If to take any program of data handling, it: A> 1. Reads the data (query generator, mapper), A> 2. Changes them (change tracker), A> 3. Saves changed (query generator, mapper, conflict resolver). Interesting - how much well it builds sequence of changes which are rolled on (relational) database. And as it is possible to influence this process. For example - renumbering of documents. Was: 2,3,1. Became: 1,2,3. Column DocNumber unique, but is not primary key. Proceeding from the experience with replication of enough difficult and large database (registration of transactions with real estate of the Lipetsk region, 2000-2008) is is under construction the oriented graph (without cycles) which then in some passes is rolled on basis. I think, too most should be and in ORM. And probably there are methods to be built in processes of formation of this graph and it .

41

Re: That does not suffice in heavy ORM?

Hello, Kovalenko Dmitry, you wrote: IT>> I even would specify. It is difficult to invent application  orm outside of demonstration projects. > Each time when I reflect on learning and adding of support any ORM, I will come across judgement similar to it It means that the people at last started to understand all vicious essence heavy ORM Actually all simply. The same Identity Map works for objects which are displayed on DB tables. If all object in storages or my request generally is not necessary to me implies a combination of the data from several tables or even aggregates Identity Map goes a forest park. And such requests in more less decent applications of percent  95. Actually, scenarios in which objects which are required to application entirely is an editing of handbook data, well and fine looks in demos. > All these EF, Hibernate - they that, really such useless in industrial (in the sense, heaped up to horror) systems? Are not absolutely useless. If to estimate their usefulness, it somewhere 0.5 of 10. Are more precisely useless not in itself ORM entirely, and them Entity Services like the same Identity Map. If in ORM such services are not disconnected, there will be problems. I use ORM years 15, thus necessity in Entity Services arose I do not remember even as often. If the need in it was  sharp in linq2db it is all for a long time already would appear. But while  it is not necessary.

42

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: A>>> it is strange to demand from orm such functionality: truncate table is ddl which is similar to calls drop table and create table with  indexes, keys and triggers. And ddl in orm should appear only at level of migrations. IT>> temporary tables? A> temporary tables as means to avoid truncate, or you ask about necessity to do truncate temporary tables? I about DDL as a whole. And truncate  happens it is necessary. I here expect passage to a SQL Server 2014 (in office with it a problem) to implement truncate for partitions, and idle time truncate is used not too rarely. In the core for cleaning staging tables. A> in the same oracle temporary tables within session (transaction) differ from normal a little, and outside of table session it is possible to clean and without orm. The general-purpose decision all not to receive. Also it is not necessary. There is enough not of absolutely general-purpose, and we tell so more less general-purpose on 99 %. With remained percent somehow we consult.

43

Re: That does not suffice in heavy ORM?

44

Re: That does not suffice in heavy ORM?

IT> Actually all is simple. The same Identity Map works for objects which are displayed on DB tables. In Identity Map o are reflected not on tables, and for lines of tables. IT> if all object in storage you is not necessary to me mean, what all fields of the object, for example any big BLOB a field are necessary not? If so, here a problem not in Identity Map (IM Further). This pattern does not contradict that at first to load in IM object with partially filled fields, we admit to show to the user, then, after obtaining of additional fields from a DB to change earlier loaded IM object. Another matter what not all heavy ORM allow to update easily already loaded in IM objects. IT> or my request generally implies a combination of the data from several tables or even aggregates Too I do not see a problem in pattern IM as that. If  the table-class allows to receive one request in a DB set of objects of different classes there are no problems. Load each received object in IM. Pattern IM very much helps me. Same so it is convenient and clear - single line in a DB - one object in storage. The problem of mistiming of several copies of the same data in storage leaves. By the way without problems I combine IM and Linq2Db.

45

Re: That does not suffice in heavy ORM?

Hello, Kovalenko Dmitry, you wrote: > Judging by the sizes of folders in DataProvider to try will fasten the to linq2db completely not difficult To eat something the especial?

46

Re: That does not suffice in heavy ORM?

Hello, igor-booch, you wrote: IB> In Identity Map o are reflected not on tables, and for lines of tables. Yes without a difference. What does command CREATE TABLE describe, structure of the table or structure of single line of the same table? Terminological idle talk, more shortly. IT>> if all object in storage IB> you is not necessary to me mean, what all fields of the object, for example any big BLOB a field are necessary not? If so, here a problem not in Identity Map (IM Further). This pattern does not contradict that at first to load in IM object with partially filled fields, we admit to show to the user, then, after obtaining of additional fields from a DB to change earlier loaded IM object. Another matter what not all heavy ORM allow to update easily already loaded in IM objects. With what generally sense to manipulate object and  there something necessarily if it is necessary for me right now only two fields from twenty, and the object entirely most likely generally never is required for all time of existence of application? IT>> or my request generally implies a combination of the data from several tables or even aggregates IB> Too I do not see a problem in pattern IM as that. If  the table-class allows to receive one request in a DB set of objects of different classes there are no problems. Load each received object in IM. Besides. All objects entering into request are not necessary to me. It is necessary for me two fields from one object and one of connected with it. What for to lift and create in storage the whole hierarchies if it is necessary to nobody? IB> pattern IM very much helps Me. Same so it is convenient and clear - single line in a DB - one object in storage. The problem of mistiming of several copies of the same data in storage leaves. By the way without problems I combine IM and Linq2Db. At me such tasks where there can be a problem of mistiming of several copies of the same data in storage exactly floor of percent. Though is not present, on some orders it is less. Thus I perfectly understand that all depends on personal preferences and design abilities of the specific developer. At desire it is possible to load generally all model in storage and to basis not to address any more. What here only to do, if basis in the size some terabyte?

47

Re: That does not suffice in heavy ORM?

Hello, IT, you wrote: IT> Hello, Kovalenko Dmitry, you wrote: >> Judging by the sizes of folders in DataProvider to try will fasten the to linq2db completely not difficult IT> There is something the especial? Aha the Author: Kovalenko Dmitry Data: 15.11 22:05

48

Re: That does not suffice in heavy ORM?

Hello, Kovalenko Dmitry, you wrote: > Me monsters  only when they work incorrectly. And if more slowly on the order? Too will easy watch of it? A>> if to take any program of data handling, it: A>> 1. Reads the data (query generator, mapper), A>> 2. Changes them (change tracker), A>> 3. Saves changed (query generator, mapper, conflict resolver). > it is interesting - how much well it builds sequence of changes which are rolled on (relational) database. And as it is possible to influence this process. Options for a configuration of this business a heap, you will be tired to understand, but I about another, am not clear as without superfluous costs to use orm in this case. > For example - renumbering of documents. Was: 2,3,1. Became: 1,2,3. Column DocNumber unique, but is not primary key. And if a field still the mandatory? In this case it is difficult to invent the good decision. Most simple - to give control over it to application. > Proceeding from the experience with replication of enough difficult and large database (registration of transactions with real estate of the Lipetsk region, 2000-2008) is is under construction the oriented graph (without cycles) which then in some passes is rolled on basis. > I Think, too most should be and in ORM. Here I also do not understand, if tracking objects is in application, what for it to double in orm.

49

Re: That does not suffice in heavy ORM?

Hello, igor-booch, you wrote: IB> That does not suffice you or that is not pleasant to you in modern heavy ORM. The question concerns heavy ORM (c Identity Map), superficial I do not consider. There is no sense and qualification of authors. "Rich possibilities" business stupidly does not reach usage because to begin with they cannot simply generate and implement requests basic possibilities of operation dataful - oscillations merge statement - cte -   in both sides - supports sparse columns/columnsets - do not work with tables in 200 columns - openjson anybody  does not support - where column in (<large set>) - even do not dream etc., etc. Against this feebleness sense in them it is absolutely lost

50

Re: That does not suffice in heavy ORM?

Hello, amironov79, you wrote: >> Me monsters  only when they work incorrectly. A> and if more slowly on the order? Too will easy watch of it? <Long thought>. All depends on circumstances. A> here I also do not understand, if tracking objects is in application, what for it to double in orm. Because can?