← Back to branch summary

~raginggoblin/infolog/infolog

« back to all changes in this revision

Viewing changes to InfologServer/lib/hibernate-distribution-3.3.2.GA/project/documentation/manual/src/main/docbook/fr-FR/content/portability.po

  • Committer: Raging Goblin
  • Date: 2013-11-16 16:51:32 UTC
  • Revision ID: raging_goblin-20131116165132-weujnptzc88uy4ah
Mavenized the project, now using shared project InfologSync

Show diffs side-by-side

added added

removed removed

Lines of Context:
InfologServer/lib/hibernate-distribution-3.3.2.GA/project/documentation/manual/src/main/docbook/fr-FR/content/portability.po
1
 
# Language fr-FR translations for Branch package.
2
 
# Automatically generated, 2009.
3
 
#
4
 
msgid ""
5
 
msgstr ""
6
 
"Project-Id-Version: Branch 3_3\n"
7
 
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
8
 
"POT-Creation-Date: 2009-06-23 18:41+0000\n"
9
 
"PO-Revision-Date: 2009-06-10 21:02+0000\n"
10
 
"Last-Translator: Automatically generated\n"
11
 
"Language-Team: none\n"
12
 
"MIME-Version: 1.0\n"
13
 
"Content-Type: text/plain; charset=UTF-8\n"
14
 
"Content-Transfer-Encoding: 8bit\n"
15
 
 
16
 
#. Tag: title
17
 
#: portability.xml:26
18
 
#, no-c-format
19
 
msgid "Database Portability Considerations"
20
 
msgstr ""
21
 
 
22
 
#. Tag: title
23
 
#: portability.xml:29
24
 
#, no-c-format
25
 
msgid "Portability Basics"
26
 
msgstr ""
27
 
 
28
 
#. Tag: para
29
 
#: portability.xml:31
30
 
#, no-c-format
31
 
msgid ""
32
 
"One of the selling points of Hibernate (and really Object/Relational Mapping "
33
 
"as a whole) is the notion of database portability. This could mean an "
34
 
"internal IT user migrating from one database vendor to another, or it could "
35
 
"mean a framework or deployable application consuming Hibernate to "
36
 
"simultaneously target multiple database products by their users. Regardless "
37
 
"of the exact scenario, the basic idea is that you want Hibernate to help you "
38
 
"run against any number of databases without changes to your code, and "
39
 
"ideally without any changes to the mapping metadata."
40
 
msgstr ""
41
 
 
42
 
#. Tag: title
43
 
#: portability.xml:42
44
 
#, no-c-format
45
 
msgid "Dialect"
46
 
msgstr ""
47
 
 
48
 
#. Tag: para
49
 
#: portability.xml:44
50
 
#, no-c-format
51
 
msgid ""
52
 
"The first line of portability for Hibernate is the dialect, which is a "
53
 
"specialization of the <classname>org.hibernate.dialect.Dialect</classname> "
54
 
"contract. A dialect encapsulates all the differences in how Hibernate must "
55
 
"communicate with a particular database to accomplish some task like getting "
56
 
"a sequence value or structuring a SELECT query. Hibernate bundles a wide "
57
 
"range of dialects for many of the most popular databases. If you find that "
58
 
"your particular database is not among them, it is not terribly difficult to "
59
 
"write your own."
60
 
msgstr ""
61
 
 
62
 
#. Tag: title
63
 
#: portability.xml:55
64
 
#, no-c-format
65
 
msgid "Dialect resolution"
66
 
msgstr ""
67
 
 
68
 
#. Tag: para
69
 
#: portability.xml:57
70
 
#, no-c-format
71
 
msgid ""
72
 
"Originally, Hibernate would always require that users specify which dialect "
73
 
"to use. In the case of users looking to simultaneously target multiple "
74
 
"databases with their build that was problematic. Generally this required "
75
 
"their users to configure the Hibernate dialect or defining their own method "
76
 
"of setting that value."
77
 
msgstr ""
78
 
 
79
 
#. Tag: para
80
 
#: portability.xml:64
81
 
#, no-c-format
82
 
msgid ""
83
 
"Starting with version 3.2, Hibernate introduced the notion of automatically "
84
 
"detecting the dialect to use based on the <interfacename>java.sql."
85
 
"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql."
86
 
"Connection</interfacename> to that database. This was much better, expect "
87
 
"that this resolution was limited to databases Hibernate know about ahead of "
88
 
"time and was in no way configurable or overrideable."
89
 
msgstr ""
90
 
 
91
 
#. Tag: para
92
 
#: portability.xml:72
93
 
#, no-c-format
94
 
msgid ""
95
 
"Starting with version 3.3, Hibernate has a fare more powerful way to "
96
 
"automatically determine which dialect to should be used by relying on a "
97
 
"series of delegates which implement the <interfacename>org.hibernate.dialect."
98
 
"resolver.DialectResolver</interfacename> which defines only a single method:"
99
 
"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData "
100
 
"metaData) throws JDBCConnectionException]]></programlisting>. The basic "
101
 
"contract here is that if the resolver 'understands' the given database "
102
 
"metadata then it returns the corresponding Dialect; if not it returns null "
103
 
"and the process continues to the next resolver. The signature also "
104
 
"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</"
105
 
"exceptionname> as possibly being thrown. A JDBCConnectionException here is "
106
 
"interpreted to imply a \"non transient\" (aka non-recoverable) connection "
107
 
"problem and is used to indicate an immediate stop to resolution attempts. "
108
 
"All other exceptions result in a warning and continuing on to the next "
109
 
"resolver."
110
 
msgstr ""
111
 
 
112
 
#. Tag: para
113
 
#: portability.xml:85
114
 
#, no-c-format
115
 
msgid ""
116
 
"The cool part about these resolvers is that users can also register their "
117
 
"own custom resolvers which will be processed ahead of the built-in Hibernate "
118
 
"ones. This might be useful in a number of different situations: it allows "
119
 
"easy integration for auto-detection of dialects beyond those shipped with "
120
 
"HIbernate itself; it allows you to specify to use a custom dialect when a "
121
 
"particular database is recognized; etc. To register one or more resolvers, "
122
 
"simply specify them (seperated by commas, tabs or spaces) using the "
123
 
"'hibernate.dialect_resolvers' configuration setting (see the "
124
 
"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate."
125
 
"cfg.Environment</classname>)."
126
 
msgstr ""
127
 
 
128
 
#. Tag: title
129
 
#: portability.xml:98
130
 
#, no-c-format
131
 
msgid "Identifier generation"
132
 
msgstr ""
133
 
 
134
 
#. Tag: para
135
 
#: portability.xml:100
136
 
#, no-c-format
137
 
msgid ""
138
 
"When considering portability between databases, another important decision "
139
 
"is selecting the identifier generation stratagy you want to use. Originally "
140
 
"Hibernate provided the <emphasis>native</emphasis> generator for this "
141
 
"purpose, which was intended to select between a <emphasis>sequence</"
142
 
"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> "
143
 
"strategy depending on the capability of the underlying database. However, an "
144
 
"insidious implication of this approach comes about when targtetting some "
145
 
"databases which support <emphasis>identity</emphasis> generation and some "
146
 
"which do not. <emphasis>identity</emphasis> generation relies on the SQL "
147
 
"definition of an IDENTITY (or auto-increment) column to manage the "
148
 
"identifier value; it is what is known as a post-insert generation strategy "
149
 
"becauase the insert must actually happen before we can know the identifier "
150
 
"value. Because Hibernate relies on this identifier value to uniquely "
151
 
"reference entities within a persistence context it must then issue the "
152
 
"insert immediately when the users requests the entitiy be associated with "
153
 
"the session (like via save() e.g.) regardless of current transactional "
154
 
"semantics. <note> <para> Hibernate was changed slightly once the implication "
155
 
"of this was better understood so that the insert is delayed in cases where "
156
 
"that is feasible. </para> </note> The underlying issue is that the actual "
157
 
"semanctics of the application itself changes in these cases."
158
 
msgstr ""
159
 
 
160
 
#. Tag: para
161
 
#: portability.xml:125
162
 
#, no-c-format
163
 
msgid ""
164
 
"Starting with version 3.2.3, Hibernate comes with a set of <ulink url="
165
 
"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators "
166
 
"targetting portability in a much different way. <note> <para> There are "
167
 
"specifically 2 bundled <emphasis>enhanced</emphasis>generators: "
168
 
"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced."
169
 
"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> "
170
 
"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </"
171
 
"listitem> </itemizedlist> </para> </note> The idea behind these generators "
172
 
"is to port the actual semantics of the identifer value generation to the "
173
 
"different databases. For example, the <classname>org.hibernate.id.enhanced."
174
 
"SequenceStyleGenerator</classname> mimics the behavior of a sequence on "
175
 
"databases which do not support sequences by using a table."
176
 
msgstr ""
177
 
 
178
 
#. Tag: title
179
 
#: portability.xml:154
180
 
#, no-c-format
181
 
msgid "Database functions"
182
 
msgstr ""
183
 
 
184
 
#. Tag: para
185
 
#: portability.xml:157
186
 
#, no-c-format
187
 
msgid ""
188
 
"This is an area in Hibernate in need of improvement. In terms of portability "
189
 
"concerns, this function handling currently works pretty well from HQL; "
190
 
"however, it is quite lacking in all other aspects."
191
 
msgstr ""
192
 
 
193
 
#. Tag: para
194
 
#: portability.xml:164
195
 
#, no-c-format
196
 
msgid ""
197
 
"SQL functions can be referenced in many ways by users. However, not all "
198
 
"databases support the same set of functions. Hibernate, provides a means of "
199
 
"mapping a <emphasis>logical</emphasis> function name to a a delegate which "
200
 
"knows how to render that particular function, perhaps even using a totally "
201
 
"different physical function call."
202
 
msgstr ""
203
 
 
204
 
#. Tag: para
205
 
#: portability.xml:170
206
 
#, no-c-format
207
 
msgid ""
208
 
"Technically this function registration is handled through the <classname>org."
209
 
"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is "
210
 
"intended to allow users to provide custom function definitions without "
211
 
"having to provide a custom dialect. This specific behavior is not fully "
212
 
"completed as of yet."
213
 
msgstr ""
214
 
 
215
 
#. Tag: para
216
 
#: portability.xml:177
217
 
#, no-c-format
218
 
msgid ""
219
 
"It is sort of implemented such that users can programatically register "
220
 
"functions with the <classname>org.hibernate.cfg.Configuration</classname> "
221
 
"and those functions will be recognized for HQL."
222
 
msgstr ""
223
 
 
224
 
#. Tag: title
225
 
#: portability.xml:187
226
 
#, no-c-format
227
 
msgid "Type mappings"
228
 
msgstr ""
229
 
 
230
 
#. Tag: para
231
 
#: portability.xml:189
232
 
#, no-c-format
233
 
msgid "This section scheduled for completion at a later date..."
234
 
msgstr ""