1

Topic: About Hibernate

Came across a post criticizing hibernate which that seems exaggerated, but some problems faced itself. It will be possible useful to a sight at conveniences  on the other hand. There still there is a link to presentation where it is shown that complexity even manual  is strongly exaggerated at usage something like Spring JDBC Template.

2

Re: About Hibernate

Hello, A13x, you wrote: A> Came across a post criticizing hibernate which that seems exaggerated, but some problems faced itself. A> it will be possible useful to a sight at conveniences  on the other hand. A> there still there is a link to presentation where it is shown that complexity even manual  is strongly exaggerated at usage something like Spring JDBC Template. , of course,  and, in my judgement, it cannot to allow be used to people who cannot and never wrote requests hands. But in article somehow the emphasis goes on a brothel with basis structure - in this Hiberneyot is not guilty Structure and migration between versions it is possible to do bypassing Hibernejta and to them even it advised from the very beginning.

3

Re: About Hibernate

Hello, bzig, you wrote: B> Hibernejt, of course, ... And what its singularities do of it ""?

4

Re: About Hibernate

Hello, bzig, you wrote: B>... B>, of course,  and, in my judgement, it it is impossible to allow to use Hibernejt to people who cannot and never wrote requests hands. But in article somehow the emphasis goes on a brothel with basis structure - in this Hiberneyot is not guilty Structure and migration between versions it is possible to do bypassing Hibernejta and to them even it advised from the very beginning. There not only it, the author then added lacks and myths  in the presentation - the part from them is reflected and in article: Myths: need to worry about SQL DRY communication Easy relation management Easy query refactoring boilerplate Type-safety Easy migrations Unification between databases Easy scale* Easy cache Easy multi-tenant Cons: HDD, Hibernate Driven Development, One way ticket and long term suffering, Bad SQL abstraction, Multi SQL abstraction (Native query, HQL, detached criteria ...) Useless features (stamping, versioning, locking), Generated schema = bad design, 3 schemas Gotchas! (ex. HQL LIMIT) well and the most important thing - performance (it figured in article as a large problem of the project) - and there it evolved from an initial postulate that  the model will be good enough for fulfilling on great volumes of the data and yes though it too concerns structural problems, but an essence that necessity of the full understanding SQL almost completely kills all value proposition  - "... We are trying to use native SQL as much as possible since performance is crucial at the moment". And the same things (sql-> model mapping) are reached by more simple and effective methods (jdbctemplate, fluent jdbc wrapper).

5

Re: About Hibernate

Hello, A13x, you wrote: A> There not only it, the author then added lacks and myths  in the presentation - the part from them is reflected and in article: skipped... A> well and the most important thing - performance (it figured in article as a large problem of the project) - and there it evolved from an initial postulate that  the model will be good enough for fulfilling on great volumes of the data and yes though it too concerns structural problems, but an essence that necessity of the full understanding SQL almost completely kills all value proposition  - "... We are trying to use native SQL as much as possible since performance is crucial at the moment". A> And the same things (sql-> model mapping) are reached by more simple and effective methods (jdbctemplate, fluent jdbc wrapper). To tell the truth, article is more similar to revelations of the person with pair - triple of years of experience which suddenly assigned  the new and difficult project.  deserved to itself a place in many if not in the majority projects, but yes, the understanding in what cases cannot be used it to be. And it can quite coexist and with jdbctemplate. In the majority cases development crud operations over specific  with  happens on the order faster, but it is necessary to understand, as as it will pull from basis. If someone decided to build any analytic reports with the help  yes, then there are such here articles. In general, to each tool the task.

6

Re: About Hibernate

PZI> In the majority cases development crud operations over specific  with  happens on the order faster, but it is necessary to understand, as as it will pull from basis. Here on this all also are bought. Here only development  operations from the general time of the project makes less than 1 % and with Hibernejtom becomes less than 0.1 % And time for trials why somewhere something got/not got to a cache, the object fell off session,  and incorrectly works, SUDDENLY starts to occupy 10 %.

7

Re: About Hibernate

Hello, PZI, you wrote: PZI> Hello, bzig, you wrote: B>> Hibernejt, of course, ... PZI> And what its singularities do of it ""? I did the  when Envers th also did not smell and saw enough of interiors of Hibernejta. Since then at me a mental trauma - each time in the late autumn when children in park start to roll snowmen from the first snow, winding in snow clods of the branch, fallen down foliage and sand - I recall at once the code of Hibernejta.

8

Re: About Hibernate

A> that necessity of the full understanding SQL almost completely kills all value proposition  Here it, actually, the principal

9

Re: About Hibernate

Hello, bzig, you wrote: B> Here on this all also are bought. Here only development  operations from the general time of the project makes less than 1 % and with Hibernejtom becomes less than 0.1 % B> And time for trials why somewhere something got/not got to a cache, the object fell off session,  and incorrectly works, SUDDENLY starts to occupy 10 %. Well here the statement that in all projects crud makes 1 % - too courageous. Projects too different. Is and 100 %, are and 0 %. And time for trials already directly depends on knowledge and experience of the developer. At first yes, a lot of time is spent, but then when you understand as it all works, errors almost do not admit, and if admit, quickly enough them find.

10

Re: About Hibernate

Hello, bzig, you wrote: B> I did the  when Envers th also did not smell and saw enough of interiors of Hibernejta. Since then at me a mental trauma - each time in the late autumn when children in park start to roll snowmen from the first snow, winding in snow clods of the branch, fallen down foliage and sand - I recall at once the code of Hibernejta. Well, I too had so to correct well enough the code  for  very much the specific task. There all is finite is heaped up much, but as a whole the code was pleasant to me. Truth it was about 6 years ago, I do not know as now. But, it seems to me the question just about does not concern "normal" usage , and what its singularities do of it  at usage "as is"

11

Re: About Hibernate

Hello, A13x, you wrote: A> There not only it, the author then added lacks and myths  in the presentation - the part from them is reflected and in article: the Author of presentation possibly specially did not show as look  update through jdbctemplate. And as affairs with entity relationships are at usage jdbctemplate too concealed. And as it is easy to add/delete fields in/from  in the middle, and even by the project end. In general, this article/presentation of the objective did not seem to me. Certainly, there are many situations where to use  it is impossible, but it does not mean that the statement "do not use " which as a matter of fact is the motto of this article, truly.

12

Re: About Hibernate

PZI> Well here the statement that in all projects crud makes 1 % - too courageous. Projects too different. Is and 100 %, are and 0 %. Anything it not courageous, normal statement PZI> At first yes, is spent a lot of time, Here all advantage and left in pipe PZI> but then when you understand as it all works, errors almost do not admit, and if admit, quickly enough them find. When you become the expert on Hibernejtu and SQL, the desire it at once disappears to use, because understand, it how much is not enough for you does well

13

Re: About Hibernate

Hello, bzig, you wrote: B> Anything it not the courageous, normal statement I about that you try you tell for all projects. And as speak - "it is not necessary to speak for all". PZI>> At first yes, a lot of time is spent, B> Here all advantage and left in a pipe of Hiber, as well as any another  or the technology demands time for learning. This time is spent once. Further it simply use. B> when you become the expert on Hibernejtu and SQL, the desire it at once disappears to use, because understand, it how much is not enough for you does well Well, itself will not praise - nobody praises I asked to give an example above why  "" but so the answer and did not receive.

14

Re: About Hibernate

PZI> Well, yourself you will not praise - nobody praises I asked to give an example above why  "" but so the answer and did not receive.??? It is badly written and works suitably. But principal arguments against Hibernejta - it does not relieve you of knowledge SQL, in addition demands knowledge of all its singularities and it is not "transparent" for application - you permanently should remember that in application there is Hibernejt and to program with the registration of it. When at you simple layer DAO atop JdbcTemplate it just also transparently also is isolated.

15

Re: About Hibernate

Hello, bzig, you wrote: B>??? It is badly written and works suitably. Excellent argument! Or it is an axiom? B> but principal arguments against Hibernejta - it does not relieve you of knowledge SQL, in addition demands knowledge of all its singularities and it is not "transparent" for application - you permanently should remember that in application there is Hibernejt and to program with the registration of it. It agree! Truth not clearly why is minuses. Yes, that something to use, it is necessary to be able to these to use and use it without forgetting that you use it And about knowledge SQL, it generally strange "minus". A minus, if the developer does not know it SQL. B> When at you simple layer DAO atop JdbcTemplate it just also transparently also is isolated. I already wrote more low, about that the author of article/presentation for some reason did not tell as easily to implement update  with the help jdbctemplate. Well it is natural at  still there are any relations to another , and these most  too could ... Well also it is finite, about control in a crowd he did not tell transactions. How you think, why it forgot? The word in expression "simple layer DAO atop JdbcTemplate" should be quoted "idle time" if to tell about it. Actually here already similar faith, time arguments miss. And to overpersuade the believing person, at me desires are not present.

16

Re: About Hibernate

Hello, PZI, you wrote: PZI> Hello, A13x, you wrote: A>> There not only it, the author then added lacks and myths  in the presentation - the part from them is reflected and in article: PZI> the Author of presentation possibly specially did not show as look  update through jdbctemplate. And as affairs with entity relationships are at usage jdbctemplate too concealed. And as it is easy to add/delete fields in/from  in the middle, and even by the project end. And in what a problem? I actually do not see complexities in the type code db.update ("INSERT INTO entity (field1, field2)", val1, val2); Concerning removal of fields is always in a different level painfully in the grocery code, but anything outstanding I do not see. PZI> in general, this article/presentation of the objective did not seem to me. Certainly, there are many situations where to use  it is impossible, but it does not mean that the statement "do not use " which as a matter of fact is the motto of this article, truly. As a matter of fact article inference - usage  does not give any scoring on comparing even with handwork from a DB -  in itself abstraction full of holes (leaky abstraction) as it not smart enough for the full abstraction of a layer of the data, and the code  the data can be written with usage of more simple and well-tried remedies. All this history with  - one more acknowledgement of viability of a principle of usage of a combination of tools well ground under the narrow task against usage of the general-purpose library which can do a heap of things - in a case with  there both  and  the data and generation of the circuit and . Well and after I of tears with  also began to use in new projects jdbc template I categorically do not agree that with  to write the code much faster and I see it from the practical experience. For simple bases and simple CRUD scenarios the overhead projector of the manual code is minimum (and there is a complete control), and for difficult with  it is much more than fuss.

17

Re: About Hibernate

Hello, bzig, you wrote: PZI>> In the majority cases development crud operations over specific  with  happens on the order faster, but it is necessary to understand, as as it will pull from basis. B> here on this all also are bought. Here only development  operations from the general time of the project makes less than 1 % and with Hibernejtom becomes less than 0.1 % B> And time for trials why somewhere something got/not got to a cache, the object fell off session,  and incorrectly works, SUDDENLY starts to occupy 10 %. I wrote on 100 %  the project.  helped. It  generally a miracle. But it agree -  difficult, to take it, not to know SQL - sense a zero.

18

Re: About Hibernate

B>>??? It is badly written and works suitably. PZI> Excellent argument! Or it is an axiom? This judgement B>> But principal arguments against Hibernejta - it does not relieve you of knowledge SQL, in addition demands knowledge of all its singularities and it is not "transparent" for application - you permanently should remember that in application there is Hibernejt and to program with the registration of it. PZI> it agree! Truth not clearly why is minuses. Yes, that something to use, it is necessary to be able to these to use and use it without forgetting that you use it And about knowledge SQL, it generally strange "minus". A minus, if the developer does not know it SQL. Because it as porridge from an axe - the axe is not necessary. PZI> I already wrote more low, about that the author of article/presentation for some reason did not tell as easily to implement update  with the help jdbctemplate. Well it is natural at  still there are any relations to another , and these most  too could . . Well here when the developer ceases to supervise that at it and where changes, and gives it on control of Hibernejtu, just and problems with the fallen off sessions closed by transactions, updates by transactions etc. PZI> Well begin and is finite, about control in a crowd he did not tell transactions. How you think, why it forgot? Because Spring is engaged in it.

19

Re: About Hibernate

PZI> Well here the statement that in all projects crud makes 1 % - too courageous. Projects too different. Is and 100 %, are and 0 %. "Is and 100 %" - well here in these several and use. "Is and 0 %" - on a horse-radish here ? PZI> Projects too different. Well here in  in life did not participate - everywhere  no more than 1 %, and even it is less most likely

20

Re: About Hibernate

Hello, A13x, you wrote: A> Hello, PZI, you wrote: PZI>> Hello, A13x, you wrote: A>>> There not only it, the author then added lacks and myths  in the presentation - the part from them is reflected and in article: PZI>> the Author of presentation possibly specially did not show as look  update through jdbctemplate. And as affairs with entity relationships are at usage jdbctemplate too concealed. And as it is easy to add/delete fields in/from  in the middle, and even by the project end. A> and in what a problem? I actually do not see complexities in the type code db.update ("INSERT INTO entity (field1, field2)", val1, val2); A> Concerning removal of fields is always in a different level painfully in the grocery code, but anything outstanding I do not see. PZI>> in general, this article/presentation of the objective did not seem to me. Certainly, there are many situations where to use  it is impossible, but it does not mean that the statement "do not use " which as a matter of fact is the motto of this article, truly. A> as a matter of fact article inference - usage  does not give any scoring on comparing even with handwork from a DB -  in itself abstraction full of holes (leaky abstraction) as it not smart enough for the full abstraction of a layer of the data, and the code  the data can be written with usage of more simple and well-tried remedies. All this history with  - one more acknowledgement of viability of a principle of usage of a combination of tools well ground under the narrow task against usage of the general-purpose library which can do a heap of things - in a case with  there both  and  the data and generation of the circuit and . A> Well and after I of tears with  also began to use in new projects jdbc template I categorically it do not agree that with  to write the code much faster and I see it from the practical experience. A> for simple bases and simple CRUD scenarios the overhead projector of the manual code is minimum (and there is a complete control), and for difficult with  it is much more than fuss. On simple examples all is beautiful. And in what attempt to read business object of 5 nesting levels having at least, including collections, and also its subsequent insert or update in basis turns. Can share best practics.

21

Re: About Hibernate

Hello, 6lackbird, you wrote: 6> And in what attempt to read business object of 5 nesting levels having at least, including collections, and also its subsequent insert or update in basis turns. 6> can share best practics. best practices: not to read and especially not  such branchy tree of objects... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

22

Re: About Hibernate

Hello, 6lackbird, you wrote: 6> On simple examples all is beautiful. 6> and in what attempt to read business object of 5 nesting levels having at least, including collections, and also its subsequent insert or update in basis turns. 6> can share best practics. By the way, with  at manipulations with such trees it will be necessary to observe 100500 "" restrictions differently  everyones "deleted object would be re-saved by cascade" and other beauty... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

23

Re: About Hibernate

8/2/2017 11:38, 6lackbird writes:> And in what attempt to read business object having at least 5> nesting levels, including collections, and also its subsequent insert> or update in basis turns.>> can share best practics. The main thing - to take measures to a non-admission of that designed that left descendants. - WBR, Serge. Posted via RSDN NNTP Server 2.1 beta

24

Re: About Hibernate

Hello, 6lackbird, you wrote: 6>... 6> On simple examples all is beautiful. 6> and in what attempt to read business object of 5 nesting levels having at least, including collections, and also its subsequent insert or update in basis turns. 6> can share best practics. Yes, certainly. If there is a possibility - to update only that is necessary. A simple example: the relation the user-role. At adding of a new role it is not necessary to update object "user", it is necessary to add simply new communication with a role, etc. Sometimes it really difficult to make. I some times in the life worked with rather large systems eCommerce in the different companies including with a world name. And, for example, in services of users controlling orders (order) it is necessary to deal very much with an enclosure deep water (an example from real life: order-> line item [i]-> fulfillment state-> fulfillment quantity item [j]-> refunds [k]-> reason). And so, in such practical task sacrifice beauty and normalization and store warrants in similarity key-value storages (i.e. the warrant is stored as ) and do indexes only on a small number of the carried out and prodoubled fields (e.g. for date of creation of the order). Thus () at any update of the order one update on all blob-object of the order and depending on becomes, whether is among updated fields entering into indexes are updated and carried out indexed too. On the other hand there are tasks analytics business under warrants and as a rule for these tasks do separate basis with the normalized data where periodically overtake updates from basis of service of orders. And on basis of analytics it is already possible to drive requests on all fields. It looks ugly, but it works in practice - alas, pure normalization no means always well works on great volumes so depending on the task and practical operation dataful it is necessary to sacrifice something.

25

Re: About Hibernate

Hello, PZI, you wrote: PZI> Well, I too had so to correct well enough the code  for  very much the specific task. There all is finite is heaped up much, but as a whole the code was pleasant to me. Truth it was about 6 years ago, I do not know as now. PZI> But, it seems to me the question just about does not concern "normal" usage , and what its singularities do of it  at usage "as is" It by the way in due course , 12 years ago all was more sad.