[hibernate-commits] Hibernate SVN: r16878 - in core/branches/Branch_3_3/documentation/manual/src/main/docbook: es-ES/content and 5 other directories.

Author: steve.ebersole(a)jboss.com Date: 2009-06-23 01:46:34 -0400 (Tue, 23 Jun 2009) New Revision: 16878 Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/es-ES/content/portability.po core/branches/Branch_3_3/documentation/manual/src/main/docbook/fr-FR/content/portability.po core/branches/Branch_3_3/documentation/manual/src/main/docbook/ja-JP/content/portability.po core/branches/Branch_3_3/documentation/manual/src/main/docbook/ko-KR/content/portability.po core/branches/Branch_3_3/documentation/manual/src/main/docbook/pt-BR/content/portability.po core/branches/Branch_3_3/documentation/manual/src/main/docbook/zh-CN/content/portability.po Modified: core/branches/Branch_3_3/documentation/manual/src/main/docbook/en-US/content/portability.xml Log: HHH-3944 - Document known database portability strategies Modified: core/branches/Branch_3_3/documentation/manual/src/main/docbook/en-US/content/portability.xml =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/en-US/content/portability.xml 2009-06-23 05:46:17 UTC (rev 16877) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/en-US/content/portability.xml 2009-06-23 05:46:34 UTC (rev 16878) @@ -90,7 +90,7 @@ database is recognized; etc. To register one or more resolvers, simply specify them (seperated by commas, tabs or spaces) using the 'hibernate.dialect_resolvers' configuration setting (see the <constant>DIALECT_RESOLVERS</constant> constant on - <ooclass><package>org.hibernate.cfg</package><classname>Environment</classname></ooclass>). + <classname>org.hibernate.cfg.Environment</classname>). </para> </sect1> Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/es-ES/content/portability.po =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/es-ES/content/portability.po (rev 0) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/es-ES/content/portability.po 2009-06-23 05:46:34 UTC (rev 16878) @@ -0,0 +1,234 @@ +# Language es-ES translations for Branch package. +# Automatically generated, 2009. +# +msgid "" +msgstr "" +"Project-Id-Version: Branch 3_3\n" +"Report-Msgid-Bugs-To: http://bugs.kde.org\n" +"POT-Creation-Date: 2009-06-16 18:47+0000\n" +"PO-Revision-Date: 2009-06-16 18:47+0000\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Tag: title +#: portability.xml:26 +#, no-c-format +msgid "Database Portability Considerations" +msgstr "" + +#. Tag: title +#: portability.xml:29 +#, no-c-format +msgid "Portability Basics" +msgstr "" + +#. Tag: para +#: portability.xml:31 +#, no-c-format +msgid "" +"One of the selling points of Hibernate (and really Object/Relational Mapping " +"as a whole) is the notion of database portability. This could mean an " +"internal IT user migrating from one database vendor to another, or it could " +"mean a framework or deployable application consuming Hibernate to " +"simultaneously target multiple database products by their users. Regardless " +"of the exact scenario, the basic idea is that you want Hibernate to help you " +"run against any number of databases without changes to your code, and " +"ideally without any changes to the mapping metadata." +msgstr "" + +#. Tag: title +#: portability.xml:42 +#, no-c-format +msgid "Dialect" +msgstr "" + +#. Tag: para +#: portability.xml:44 +#, no-c-format +msgid "" +"The first line of portability for Hibernate is the dialect, which is a " +"specialization of the <classname>org.hibernate.dialect.Dialect</classname> " +"contract. A dialect encapsulates all the differences in how Hibernate must " +"communicate with a particular database to accomplish some task like getting " +"a sequence value or structuring a SELECT query. Hibernate bundles a wide " +"range of dialects for many of the most popular databases. If you find that " +"your particular database is not among them, it is not terribly difficult to " +"write your own." +msgstr "" + +#. Tag: title +#: portability.xml:55 +#, no-c-format +msgid "Dialect resolution" +msgstr "" + +#. Tag: para +#: portability.xml:57 +#, no-c-format +msgid "" +"Originally, Hibernate would always require that users specify which dialect " +"to use. In the case of users looking to simultaneously target multiple " +"databases with their build that was problematic. Generally this required " +"their users to configure the Hibernate dialect or defining their own method " +"of setting that value." +msgstr "" + +#. Tag: para +#: portability.xml:64 +#, no-c-format +msgid "" +"Starting with version 3.2, Hibernate introduced the notion of automatically " +"detecting the dialect to use based on the <interfacename>java.sql." +"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql." +"Connection</interfacename> to that database. This was much better, expect " +"that this resolution was limited to databases Hibernate know about ahead of " +"time and was in no way configurable or overrideable." +msgstr "" + +#. Tag: para +#: portability.xml:72 +#, no-c-format +msgid "" +"Starting with version 3.3, Hibernate has a fare more powerful way to " +"automatically determine which dialect to should be used by relying on a " +"series of delegates which implement the <interfacename>org.hibernate.dialect." +"resolver.DialectResolver</interfacename> which defines only a single method:" +"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData " +"metaData) throws JDBCConnectionException]]></programlisting>. The basic " +"contract here is that if the resolver 'understands' the given database " +"metadata then it returns the corresponding Dialect; if not it returns null " +"and the process continues to the next resolver. The signature also " +"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</" +"exceptionname> as possibly being thrown. A JDBCConnectionException here is " +"interpreted to imply a \"non transient\" (aka non-recoverable) connection " +"problem and is used to indicate an immediate stop to resolution attempts. " +"All other exceptions result in a warning and continuing on to the next " +"resolver." +msgstr "" + +#. Tag: para +#: portability.xml:85 +#, no-c-format +msgid "" +"The cool part about these resolvers is that users can also register their " +"own custom resolvers which will be processed ahead of the built-in Hibernate " +"ones. This might be useful in a number of different situations: it allows " +"easy integration for auto-detection of dialects beyond those shipped with " +"HIbernate itself; it allows you to specify to use a custom dialect when a " +"particular database is recognized; etc. To register one or more resolvers, " +"simply specify them (seperated by commas, tabs or spaces) using the " +"'hibernate.dialect_resolvers' configuration setting (see the " +"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate." +"cfgEnvironment</classname>)." +msgstr "" + +#. Tag: title +#: portability.xml:98 +#, no-c-format +msgid "Identifier generation" +msgstr "" + +#. Tag: para +#: portability.xml:100 +#, no-c-format +msgid "" +"When considering portability between databases, another important decision " +"is selecting the identifier generation stratagy you want to use. Originally " +"Hibernate provided the <emphasis>native</emphasis> generator for this " +"purpose, which was intended to select between a <emphasis>sequence</" +"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> " +"strategy depending on the capability of the underlying database. However, an " +"insidious implication of this approach comes about when targtetting some " +"databases which support <emphasis>identity</emphasis> generation and some " +"which do not. <emphasis>identity</emphasis> generation relies on the SQL " +"definition of an IDENTITY (or auto-increment) column to manage the " +"identifier value; it is what is known as a post-insert generation strategy " +"becauase the insert must actually happen before we can know the identifier " +"value. Because Hibernate relies on this identifier value to uniquely " +"reference entities within a persistence context it must then issue the " +"insert immediately when the users requests the entitiy be associated with " +"the session (like via save() e.g.) regardless of current transactional " +"semantics. <note> <para> Hibernate was changed slightly once the implication " +"of this was better understood so that the insert is delayed in cases where " +"that is feasible. </para> </note> The underlying issue is that the actual " +"semanctics of the application itself changes in these cases." +msgstr "" + +#. Tag: para +#: portability.xml:125 +#, no-c-format +msgid "" +"Starting with version 3.2.3, Hibernate comes with a set of <ulink url=" +"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators " +"targetting portability in a much different way. <note> <para> There are " +"specifically 2 bundled <emphasis>enhanced</emphasis>generators: " +"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> " +"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </" +"listitem> </itemizedlist> </para> </note> The idea behind these generators " +"is to port the actual semantics of the identifer value generation to the " +"different databases. For example, the <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> mimics the behavior of a sequence on " +"databases which do not support sequences by using a table." +msgstr "" + +#. Tag: title +#: portability.xml:154 +#, no-c-format +msgid "Database functions" +msgstr "" + +#. Tag: para +#: portability.xml:157 +#, no-c-format +msgid "" +"This is an area in Hibernate in need of improvement. In terms of portability " +"concerns, this function handling currently works pretty well from HQL; " +"however, it is quite lacking in all other aspects." +msgstr "" + +#. Tag: para +#: portability.xml:164 +#, no-c-format +msgid "" +"SQL functions can be referenced in many ways by users. However, not all " +"databases support the same set of functions. Hibernate, provides a means of " +"mapping a <emphasis>logical</emphasis> function name to a a delegate which " +"knows how to render that particular function, perhaps even using a totally " +"different physical function call." +msgstr "" + +#. Tag: para +#: portability.xml:170 +#, no-c-format +msgid "" +"Technically this function registration is handled through the <classname>org." +"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is " +"intended to allow users to provide custom function definitions without " +"having to provide a custom dialect. This specific behavior is not fully " +"completed as of yet." +msgstr "" + +#. Tag: para +#: portability.xml:177 +#, no-c-format +msgid "" +"It is sort of implemented such that users can programatically register " +"functions with the <classname>org.hibernate.cfg.Configuration</classname> " +"and those functions will be recognized for HQL." +msgstr "" + +#. Tag: title +#: portability.xml:187 +#, no-c-format +msgid "Type mappings" +msgstr "" + +#. Tag: para +#: portability.xml:189 +#, no-c-format +msgid "This section scheduled for completion at a later date..." +msgstr "" Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/fr-FR/content/portability.po =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/fr-FR/content/portability.po (rev 0) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/fr-FR/content/portability.po 2009-06-23 05:46:34 UTC (rev 16878) @@ -0,0 +1,234 @@ +# Language fr-FR translations for Branch package. +# Automatically generated, 2009. +# +msgid "" +msgstr "" +"Project-Id-Version: Branch 3_3\n" +"Report-Msgid-Bugs-To: http://bugs.kde.org\n" +"POT-Creation-Date: 2009-06-16 18:47+0000\n" +"PO-Revision-Date: 2009-06-10 21:02+0000\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Tag: title +#: portability.xml:26 +#, no-c-format +msgid "Database Portability Considerations" +msgstr "" + +#. Tag: title +#: portability.xml:29 +#, no-c-format +msgid "Portability Basics" +msgstr "" + +#. Tag: para +#: portability.xml:31 +#, no-c-format +msgid "" +"One of the selling points of Hibernate (and really Object/Relational Mapping " +"as a whole) is the notion of database portability. This could mean an " +"internal IT user migrating from one database vendor to another, or it could " +"mean a framework or deployable application consuming Hibernate to " +"simultaneously target multiple database products by their users. Regardless " +"of the exact scenario, the basic idea is that you want Hibernate to help you " +"run against any number of databases without changes to your code, and " +"ideally without any changes to the mapping metadata." +msgstr "" + +#. Tag: title +#: portability.xml:42 +#, no-c-format +msgid "Dialect" +msgstr "" + +#. Tag: para +#: portability.xml:44 +#, no-c-format +msgid "" +"The first line of portability for Hibernate is the dialect, which is a " +"specialization of the <classname>org.hibernate.dialect.Dialect</classname> " +"contract. A dialect encapsulates all the differences in how Hibernate must " +"communicate with a particular database to accomplish some task like getting " +"a sequence value or structuring a SELECT query. Hibernate bundles a wide " +"range of dialects for many of the most popular databases. If you find that " +"your particular database is not among them, it is not terribly difficult to " +"write your own." +msgstr "" + +#. Tag: title +#: portability.xml:55 +#, no-c-format +msgid "Dialect resolution" +msgstr "" + +#. Tag: para +#: portability.xml:57 +#, no-c-format +msgid "" +"Originally, Hibernate would always require that users specify which dialect " +"to use. In the case of users looking to simultaneously target multiple " +"databases with their build that was problematic. Generally this required " +"their users to configure the Hibernate dialect or defining their own method " +"of setting that value." +msgstr "" + +#. Tag: para +#: portability.xml:64 +#, no-c-format +msgid "" +"Starting with version 3.2, Hibernate introduced the notion of automatically " +"detecting the dialect to use based on the <interfacename>java.sql." +"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql." +"Connection</interfacename> to that database. This was much better, expect " +"that this resolution was limited to databases Hibernate know about ahead of " +"time and was in no way configurable or overrideable." +msgstr "" + +#. Tag: para +#: portability.xml:72 +#, no-c-format +msgid "" +"Starting with version 3.3, Hibernate has a fare more powerful way to " +"automatically determine which dialect to should be used by relying on a " +"series of delegates which implement the <interfacename>org.hibernate.dialect." +"resolver.DialectResolver</interfacename> which defines only a single method:" +"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData " +"metaData) throws JDBCConnectionException]]></programlisting>. The basic " +"contract here is that if the resolver 'understands' the given database " +"metadata then it returns the corresponding Dialect; if not it returns null " +"and the process continues to the next resolver. The signature also " +"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</" +"exceptionname> as possibly being thrown. A JDBCConnectionException here is " +"interpreted to imply a \"non transient\" (aka non-recoverable) connection " +"problem and is used to indicate an immediate stop to resolution attempts. " +"All other exceptions result in a warning and continuing on to the next " +"resolver." +msgstr "" + +#. Tag: para +#: portability.xml:85 +#, no-c-format +msgid "" +"The cool part about these resolvers is that users can also register their " +"own custom resolvers which will be processed ahead of the built-in Hibernate " +"ones. This might be useful in a number of different situations: it allows " +"easy integration for auto-detection of dialects beyond those shipped with " +"HIbernate itself; it allows you to specify to use a custom dialect when a " +"particular database is recognized; etc. To register one or more resolvers, " +"simply specify them (seperated by commas, tabs or spaces) using the " +"'hibernate.dialect_resolvers' configuration setting (see the " +"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate." +"cfgEnvironment</classname>)." +msgstr "" + +#. Tag: title +#: portability.xml:98 +#, no-c-format +msgid "Identifier generation" +msgstr "" + +#. Tag: para +#: portability.xml:100 +#, no-c-format +msgid "" +"When considering portability between databases, another important decision " +"is selecting the identifier generation stratagy you want to use. Originally " +"Hibernate provided the <emphasis>native</emphasis> generator for this " +"purpose, which was intended to select between a <emphasis>sequence</" +"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> " +"strategy depending on the capability of the underlying database. However, an " +"insidious implication of this approach comes about when targtetting some " +"databases which support <emphasis>identity</emphasis> generation and some " +"which do not. <emphasis>identity</emphasis> generation relies on the SQL " +"definition of an IDENTITY (or auto-increment) column to manage the " +"identifier value; it is what is known as a post-insert generation strategy " +"becauase the insert must actually happen before we can know the identifier " +"value. Because Hibernate relies on this identifier value to uniquely " +"reference entities within a persistence context it must then issue the " +"insert immediately when the users requests the entitiy be associated with " +"the session (like via save() e.g.) regardless of current transactional " +"semantics. <note> <para> Hibernate was changed slightly once the implication " +"of this was better understood so that the insert is delayed in cases where " +"that is feasible. </para> </note> The underlying issue is that the actual " +"semanctics of the application itself changes in these cases." +msgstr "" + +#. Tag: para +#: portability.xml:125 +#, no-c-format +msgid "" +"Starting with version 3.2.3, Hibernate comes with a set of <ulink url=" +"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators " +"targetting portability in a much different way. <note> <para> There are " +"specifically 2 bundled <emphasis>enhanced</emphasis>generators: " +"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> " +"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </" +"listitem> </itemizedlist> </para> </note> The idea behind these generators " +"is to port the actual semantics of the identifer value generation to the " +"different databases. For example, the <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> mimics the behavior of a sequence on " +"databases which do not support sequences by using a table." +msgstr "" + +#. Tag: title +#: portability.xml:154 +#, no-c-format +msgid "Database functions" +msgstr "" + +#. Tag: para +#: portability.xml:157 +#, no-c-format +msgid "" +"This is an area in Hibernate in need of improvement. In terms of portability " +"concerns, this function handling currently works pretty well from HQL; " +"however, it is quite lacking in all other aspects." +msgstr "" + +#. Tag: para +#: portability.xml:164 +#, no-c-format +msgid "" +"SQL functions can be referenced in many ways by users. However, not all " +"databases support the same set of functions. Hibernate, provides a means of " +"mapping a <emphasis>logical</emphasis> function name to a a delegate which " +"knows how to render that particular function, perhaps even using a totally " +"different physical function call." +msgstr "" + +#. Tag: para +#: portability.xml:170 +#, no-c-format +msgid "" +"Technically this function registration is handled through the <classname>org." +"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is " +"intended to allow users to provide custom function definitions without " +"having to provide a custom dialect. This specific behavior is not fully " +"completed as of yet." +msgstr "" + +#. Tag: para +#: portability.xml:177 +#, no-c-format +msgid "" +"It is sort of implemented such that users can programatically register " +"functions with the <classname>org.hibernate.cfg.Configuration</classname> " +"and those functions will be recognized for HQL." +msgstr "" + +#. Tag: title +#: portability.xml:187 +#, no-c-format +msgid "Type mappings" +msgstr "" + +#. Tag: para +#: portability.xml:189 +#, no-c-format +msgid "This section scheduled for completion at a later date..." +msgstr "" Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/ja-JP/content/portability.po =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/ja-JP/content/portability.po (rev 0) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/ja-JP/content/portability.po 2009-06-23 05:46:34 UTC (rev 16878) @@ -0,0 +1,234 @@ +# Language ja-JP translations for Branch package. +# Automatically generated, 2009. +# +msgid "" +msgstr "" +"Project-Id-Version: Branch 3_3\n" +"Report-Msgid-Bugs-To: http://bugs.kde.org\n" +"POT-Creation-Date: 2009-06-16 18:47+0000\n" +"PO-Revision-Date: 2009-06-16 18:47+0000\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Tag: title +#: portability.xml:26 +#, no-c-format +msgid "Database Portability Considerations" +msgstr "" + +#. Tag: title +#: portability.xml:29 +#, no-c-format +msgid "Portability Basics" +msgstr "" + +#. Tag: para +#: portability.xml:31 +#, no-c-format +msgid "" +"One of the selling points of Hibernate (and really Object/Relational Mapping " +"as a whole) is the notion of database portability. This could mean an " +"internal IT user migrating from one database vendor to another, or it could " +"mean a framework or deployable application consuming Hibernate to " +"simultaneously target multiple database products by their users. Regardless " +"of the exact scenario, the basic idea is that you want Hibernate to help you " +"run against any number of databases without changes to your code, and " +"ideally without any changes to the mapping metadata." +msgstr "" + +#. Tag: title +#: portability.xml:42 +#, no-c-format +msgid "Dialect" +msgstr "" + +#. Tag: para +#: portability.xml:44 +#, no-c-format +msgid "" +"The first line of portability for Hibernate is the dialect, which is a " +"specialization of the <classname>org.hibernate.dialect.Dialect</classname> " +"contract. A dialect encapsulates all the differences in how Hibernate must " +"communicate with a particular database to accomplish some task like getting " +"a sequence value or structuring a SELECT query. Hibernate bundles a wide " +"range of dialects for many of the most popular databases. If you find that " +"your particular database is not among them, it is not terribly difficult to " +"write your own." +msgstr "" + +#. Tag: title +#: portability.xml:55 +#, no-c-format +msgid "Dialect resolution" +msgstr "" + +#. Tag: para +#: portability.xml:57 +#, no-c-format +msgid "" +"Originally, Hibernate would always require that users specify which dialect " +"to use. In the case of users looking to simultaneously target multiple " +"databases with their build that was problematic. Generally this required " +"their users to configure the Hibernate dialect or defining their own method " +"of setting that value." +msgstr "" + +#. Tag: para +#: portability.xml:64 +#, no-c-format +msgid "" +"Starting with version 3.2, Hibernate introduced the notion of automatically " +"detecting the dialect to use based on the <interfacename>java.sql." +"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql." +"Connection</interfacename> to that database. This was much better, expect " +"that this resolution was limited to databases Hibernate know about ahead of " +"time and was in no way configurable or overrideable." +msgstr "" + +#. Tag: para +#: portability.xml:72 +#, no-c-format +msgid "" +"Starting with version 3.3, Hibernate has a fare more powerful way to " +"automatically determine which dialect to should be used by relying on a " +"series of delegates which implement the <interfacename>org.hibernate.dialect." +"resolver.DialectResolver</interfacename> which defines only a single method:" +"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData " +"metaData) throws JDBCConnectionException]]></programlisting>. The basic " +"contract here is that if the resolver 'understands' the given database " +"metadata then it returns the corresponding Dialect; if not it returns null " +"and the process continues to the next resolver. The signature also " +"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</" +"exceptionname> as possibly being thrown. A JDBCConnectionException here is " +"interpreted to imply a \"non transient\" (aka non-recoverable) connection " +"problem and is used to indicate an immediate stop to resolution attempts. " +"All other exceptions result in a warning and continuing on to the next " +"resolver." +msgstr "" + +#. Tag: para +#: portability.xml:85 +#, no-c-format +msgid "" +"The cool part about these resolvers is that users can also register their " +"own custom resolvers which will be processed ahead of the built-in Hibernate " +"ones. This might be useful in a number of different situations: it allows " +"easy integration for auto-detection of dialects beyond those shipped with " +"HIbernate itself; it allows you to specify to use a custom dialect when a " +"particular database is recognized; etc. To register one or more resolvers, " +"simply specify them (seperated by commas, tabs or spaces) using the " +"'hibernate.dialect_resolvers' configuration setting (see the " +"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate." +"cfgEnvironment</classname>)." +msgstr "" + +#. Tag: title +#: portability.xml:98 +#, no-c-format +msgid "Identifier generation" +msgstr "" + +#. Tag: para +#: portability.xml:100 +#, no-c-format +msgid "" +"When considering portability between databases, another important decision " +"is selecting the identifier generation stratagy you want to use. Originally " +"Hibernate provided the <emphasis>native</emphasis> generator for this " +"purpose, which was intended to select between a <emphasis>sequence</" +"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> " +"strategy depending on the capability of the underlying database. However, an " +"insidious implication of this approach comes about when targtetting some " +"databases which support <emphasis>identity</emphasis> generation and some " +"which do not. <emphasis>identity</emphasis> generation relies on the SQL " +"definition of an IDENTITY (or auto-increment) column to manage the " +"identifier value; it is what is known as a post-insert generation strategy " +"becauase the insert must actually happen before we can know the identifier " +"value. Because Hibernate relies on this identifier value to uniquely " +"reference entities within a persistence context it must then issue the " +"insert immediately when the users requests the entitiy be associated with " +"the session (like via save() e.g.) regardless of current transactional " +"semantics. <note> <para> Hibernate was changed slightly once the implication " +"of this was better understood so that the insert is delayed in cases where " +"that is feasible. </para> </note> The underlying issue is that the actual " +"semanctics of the application itself changes in these cases." +msgstr "" + +#. Tag: para +#: portability.xml:125 +#, no-c-format +msgid "" +"Starting with version 3.2.3, Hibernate comes with a set of <ulink url=" +"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators " +"targetting portability in a much different way. <note> <para> There are " +"specifically 2 bundled <emphasis>enhanced</emphasis>generators: " +"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> " +"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </" +"listitem> </itemizedlist> </para> </note> The idea behind these generators " +"is to port the actual semantics of the identifer value generation to the " +"different databases. For example, the <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> mimics the behavior of a sequence on " +"databases which do not support sequences by using a table." +msgstr "" + +#. Tag: title +#: portability.xml:154 +#, no-c-format +msgid "Database functions" +msgstr "" + +#. Tag: para +#: portability.xml:157 +#, no-c-format +msgid "" +"This is an area in Hibernate in need of improvement. In terms of portability " +"concerns, this function handling currently works pretty well from HQL; " +"however, it is quite lacking in all other aspects." +msgstr "" + +#. Tag: para +#: portability.xml:164 +#, no-c-format +msgid "" +"SQL functions can be referenced in many ways by users. However, not all " +"databases support the same set of functions. Hibernate, provides a means of " +"mapping a <emphasis>logical</emphasis> function name to a a delegate which " +"knows how to render that particular function, perhaps even using a totally " +"different physical function call." +msgstr "" + +#. Tag: para +#: portability.xml:170 +#, no-c-format +msgid "" +"Technically this function registration is handled through the <classname>org." +"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is " +"intended to allow users to provide custom function definitions without " +"having to provide a custom dialect. This specific behavior is not fully " +"completed as of yet." +msgstr "" + +#. Tag: para +#: portability.xml:177 +#, no-c-format +msgid "" +"It is sort of implemented such that users can programatically register " +"functions with the <classname>org.hibernate.cfg.Configuration</classname> " +"and those functions will be recognized for HQL." +msgstr "" + +#. Tag: title +#: portability.xml:187 +#, no-c-format +msgid "Type mappings" +msgstr "" + +#. Tag: para +#: portability.xml:189 +#, no-c-format +msgid "This section scheduled for completion at a later date..." +msgstr "" Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/ko-KR/content/portability.po =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/ko-KR/content/portability.po (rev 0) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/ko-KR/content/portability.po 2009-06-23 05:46:34 UTC (rev 16878) @@ -0,0 +1,234 @@ +# Language ko-KR translations for Branch package. +# Automatically generated, 2009. +# +msgid "" +msgstr "" +"Project-Id-Version: Branch 3_3\n" +"Report-Msgid-Bugs-To: http://bugs.kde.org\n" +"POT-Creation-Date: 2009-06-16 18:47+0000\n" +"PO-Revision-Date: 2009-06-16 18:47+0000\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Tag: title +#: portability.xml:26 +#, no-c-format +msgid "Database Portability Considerations" +msgstr "" + +#. Tag: title +#: portability.xml:29 +#, no-c-format +msgid "Portability Basics" +msgstr "" + +#. Tag: para +#: portability.xml:31 +#, no-c-format +msgid "" +"One of the selling points of Hibernate (and really Object/Relational Mapping " +"as a whole) is the notion of database portability. This could mean an " +"internal IT user migrating from one database vendor to another, or it could " +"mean a framework or deployable application consuming Hibernate to " +"simultaneously target multiple database products by their users. Regardless " +"of the exact scenario, the basic idea is that you want Hibernate to help you " +"run against any number of databases without changes to your code, and " +"ideally without any changes to the mapping metadata." +msgstr "" + +#. Tag: title +#: portability.xml:42 +#, no-c-format +msgid "Dialect" +msgstr "" + +#. Tag: para +#: portability.xml:44 +#, no-c-format +msgid "" +"The first line of portability for Hibernate is the dialect, which is a " +"specialization of the <classname>org.hibernate.dialect.Dialect</classname> " +"contract. A dialect encapsulates all the differences in how Hibernate must " +"communicate with a particular database to accomplish some task like getting " +"a sequence value or structuring a SELECT query. Hibernate bundles a wide " +"range of dialects for many of the most popular databases. If you find that " +"your particular database is not among them, it is not terribly difficult to " +"write your own." +msgstr "" + +#. Tag: title +#: portability.xml:55 +#, no-c-format +msgid "Dialect resolution" +msgstr "" + +#. Tag: para +#: portability.xml:57 +#, no-c-format +msgid "" +"Originally, Hibernate would always require that users specify which dialect " +"to use. In the case of users looking to simultaneously target multiple " +"databases with their build that was problematic. Generally this required " +"their users to configure the Hibernate dialect or defining their own method " +"of setting that value." +msgstr "" + +#. Tag: para +#: portability.xml:64 +#, no-c-format +msgid "" +"Starting with version 3.2, Hibernate introduced the notion of automatically " +"detecting the dialect to use based on the <interfacename>java.sql." +"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql." +"Connection</interfacename> to that database. This was much better, expect " +"that this resolution was limited to databases Hibernate know about ahead of " +"time and was in no way configurable or overrideable." +msgstr "" + +#. Tag: para +#: portability.xml:72 +#, no-c-format +msgid "" +"Starting with version 3.3, Hibernate has a fare more powerful way to " +"automatically determine which dialect to should be used by relying on a " +"series of delegates which implement the <interfacename>org.hibernate.dialect." +"resolver.DialectResolver</interfacename> which defines only a single method:" +"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData " +"metaData) throws JDBCConnectionException]]></programlisting>. The basic " +"contract here is that if the resolver 'understands' the given database " +"metadata then it returns the corresponding Dialect; if not it returns null " +"and the process continues to the next resolver. The signature also " +"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</" +"exceptionname> as possibly being thrown. A JDBCConnectionException here is " +"interpreted to imply a \"non transient\" (aka non-recoverable) connection " +"problem and is used to indicate an immediate stop to resolution attempts. " +"All other exceptions result in a warning and continuing on to the next " +"resolver." +msgstr "" + +#. Tag: para +#: portability.xml:85 +#, no-c-format +msgid "" +"The cool part about these resolvers is that users can also register their " +"own custom resolvers which will be processed ahead of the built-in Hibernate " +"ones. This might be useful in a number of different situations: it allows " +"easy integration for auto-detection of dialects beyond those shipped with " +"HIbernate itself; it allows you to specify to use a custom dialect when a " +"particular database is recognized; etc. To register one or more resolvers, " +"simply specify them (seperated by commas, tabs or spaces) using the " +"'hibernate.dialect_resolvers' configuration setting (see the " +"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate." +"cfgEnvironment</classname>)." +msgstr "" + +#. Tag: title +#: portability.xml:98 +#, no-c-format +msgid "Identifier generation" +msgstr "" + +#. Tag: para +#: portability.xml:100 +#, no-c-format +msgid "" +"When considering portability between databases, another important decision " +"is selecting the identifier generation stratagy you want to use. Originally " +"Hibernate provided the <emphasis>native</emphasis> generator for this " +"purpose, which was intended to select between a <emphasis>sequence</" +"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> " +"strategy depending on the capability of the underlying database. However, an " +"insidious implication of this approach comes about when targtetting some " +"databases which support <emphasis>identity</emphasis> generation and some " +"which do not. <emphasis>identity</emphasis> generation relies on the SQL " +"definition of an IDENTITY (or auto-increment) column to manage the " +"identifier value; it is what is known as a post-insert generation strategy " +"becauase the insert must actually happen before we can know the identifier " +"value. Because Hibernate relies on this identifier value to uniquely " +"reference entities within a persistence context it must then issue the " +"insert immediately when the users requests the entitiy be associated with " +"the session (like via save() e.g.) regardless of current transactional " +"semantics. <note> <para> Hibernate was changed slightly once the implication " +"of this was better understood so that the insert is delayed in cases where " +"that is feasible. </para> </note> The underlying issue is that the actual " +"semanctics of the application itself changes in these cases." +msgstr "" + +#. Tag: para +#: portability.xml:125 +#, no-c-format +msgid "" +"Starting with version 3.2.3, Hibernate comes with a set of <ulink url=" +"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators " +"targetting portability in a much different way. <note> <para> There are " +"specifically 2 bundled <emphasis>enhanced</emphasis>generators: " +"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> " +"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </" +"listitem> </itemizedlist> </para> </note> The idea behind these generators " +"is to port the actual semantics of the identifer value generation to the " +"different databases. For example, the <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> mimics the behavior of a sequence on " +"databases which do not support sequences by using a table." +msgstr "" + +#. Tag: title +#: portability.xml:154 +#, no-c-format +msgid "Database functions" +msgstr "" + +#. Tag: para +#: portability.xml:157 +#, no-c-format +msgid "" +"This is an area in Hibernate in need of improvement. In terms of portability " +"concerns, this function handling currently works pretty well from HQL; " +"however, it is quite lacking in all other aspects." +msgstr "" + +#. Tag: para +#: portability.xml:164 +#, no-c-format +msgid "" +"SQL functions can be referenced in many ways by users. However, not all " +"databases support the same set of functions. Hibernate, provides a means of " +"mapping a <emphasis>logical</emphasis> function name to a a delegate which " +"knows how to render that particular function, perhaps even using a totally " +"different physical function call." +msgstr "" + +#. Tag: para +#: portability.xml:170 +#, no-c-format +msgid "" +"Technically this function registration is handled through the <classname>org." +"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is " +"intended to allow users to provide custom function definitions without " +"having to provide a custom dialect. This specific behavior is not fully " +"completed as of yet." +msgstr "" + +#. Tag: para +#: portability.xml:177 +#, no-c-format +msgid "" +"It is sort of implemented such that users can programatically register " +"functions with the <classname>org.hibernate.cfg.Configuration</classname> " +"and those functions will be recognized for HQL." +msgstr "" + +#. Tag: title +#: portability.xml:187 +#, no-c-format +msgid "Type mappings" +msgstr "" + +#. Tag: para +#: portability.xml:189 +#, no-c-format +msgid "This section scheduled for completion at a later date..." +msgstr "" Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/pt-BR/content/portability.po =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/pt-BR/content/portability.po (rev 0) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/pt-BR/content/portability.po 2009-06-23 05:46:34 UTC (rev 16878) @@ -0,0 +1,234 @@ +# Language pt-BR translations for Branch package. +# Automatically generated, 2009. +# +msgid "" +msgstr "" +"Project-Id-Version: Branch 3_3\n" +"Report-Msgid-Bugs-To: http://bugs.kde.org\n" +"POT-Creation-Date: 2009-06-16 18:47+0000\n" +"PO-Revision-Date: 2009-06-16 18:47+0000\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Tag: title +#: portability.xml:26 +#, no-c-format +msgid "Database Portability Considerations" +msgstr "" + +#. Tag: title +#: portability.xml:29 +#, no-c-format +msgid "Portability Basics" +msgstr "" + +#. Tag: para +#: portability.xml:31 +#, no-c-format +msgid "" +"One of the selling points of Hibernate (and really Object/Relational Mapping " +"as a whole) is the notion of database portability. This could mean an " +"internal IT user migrating from one database vendor to another, or it could " +"mean a framework or deployable application consuming Hibernate to " +"simultaneously target multiple database products by their users. Regardless " +"of the exact scenario, the basic idea is that you want Hibernate to help you " +"run against any number of databases without changes to your code, and " +"ideally without any changes to the mapping metadata." +msgstr "" + +#. Tag: title +#: portability.xml:42 +#, no-c-format +msgid "Dialect" +msgstr "" + +#. Tag: para +#: portability.xml:44 +#, no-c-format +msgid "" +"The first line of portability for Hibernate is the dialect, which is a " +"specialization of the <classname>org.hibernate.dialect.Dialect</classname> " +"contract. A dialect encapsulates all the differences in how Hibernate must " +"communicate with a particular database to accomplish some task like getting " +"a sequence value or structuring a SELECT query. Hibernate bundles a wide " +"range of dialects for many of the most popular databases. If you find that " +"your particular database is not among them, it is not terribly difficult to " +"write your own." +msgstr "" + +#. Tag: title +#: portability.xml:55 +#, no-c-format +msgid "Dialect resolution" +msgstr "" + +#. Tag: para +#: portability.xml:57 +#, no-c-format +msgid "" +"Originally, Hibernate would always require that users specify which dialect " +"to use. In the case of users looking to simultaneously target multiple " +"databases with their build that was problematic. Generally this required " +"their users to configure the Hibernate dialect or defining their own method " +"of setting that value." +msgstr "" + +#. Tag: para +#: portability.xml:64 +#, no-c-format +msgid "" +"Starting with version 3.2, Hibernate introduced the notion of automatically " +"detecting the dialect to use based on the <interfacename>java.sql." +"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql." +"Connection</interfacename> to that database. This was much better, expect " +"that this resolution was limited to databases Hibernate know about ahead of " +"time and was in no way configurable or overrideable." +msgstr "" + +#. Tag: para +#: portability.xml:72 +#, no-c-format +msgid "" +"Starting with version 3.3, Hibernate has a fare more powerful way to " +"automatically determine which dialect to should be used by relying on a " +"series of delegates which implement the <interfacename>org.hibernate.dialect." +"resolver.DialectResolver</interfacename> which defines only a single method:" +"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData " +"metaData) throws JDBCConnectionException]]></programlisting>. The basic " +"contract here is that if the resolver 'understands' the given database " +"metadata then it returns the corresponding Dialect; if not it returns null " +"and the process continues to the next resolver. The signature also " +"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</" +"exceptionname> as possibly being thrown. A JDBCConnectionException here is " +"interpreted to imply a \"non transient\" (aka non-recoverable) connection " +"problem and is used to indicate an immediate stop to resolution attempts. " +"All other exceptions result in a warning and continuing on to the next " +"resolver." +msgstr "" + +#. Tag: para +#: portability.xml:85 +#, no-c-format +msgid "" +"The cool part about these resolvers is that users can also register their " +"own custom resolvers which will be processed ahead of the built-in Hibernate " +"ones. This might be useful in a number of different situations: it allows " +"easy integration for auto-detection of dialects beyond those shipped with " +"HIbernate itself; it allows you to specify to use a custom dialect when a " +"particular database is recognized; etc. To register one or more resolvers, " +"simply specify them (seperated by commas, tabs or spaces) using the " +"'hibernate.dialect_resolvers' configuration setting (see the " +"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate." +"cfgEnvironment</classname>)." +msgstr "" + +#. Tag: title +#: portability.xml:98 +#, no-c-format +msgid "Identifier generation" +msgstr "" + +#. Tag: para +#: portability.xml:100 +#, no-c-format +msgid "" +"When considering portability between databases, another important decision " +"is selecting the identifier generation stratagy you want to use. Originally " +"Hibernate provided the <emphasis>native</emphasis> generator for this " +"purpose, which was intended to select between a <emphasis>sequence</" +"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> " +"strategy depending on the capability of the underlying database. However, an " +"insidious implication of this approach comes about when targtetting some " +"databases which support <emphasis>identity</emphasis> generation and some " +"which do not. <emphasis>identity</emphasis> generation relies on the SQL " +"definition of an IDENTITY (or auto-increment) column to manage the " +"identifier value; it is what is known as a post-insert generation strategy " +"becauase the insert must actually happen before we can know the identifier " +"value. Because Hibernate relies on this identifier value to uniquely " +"reference entities within a persistence context it must then issue the " +"insert immediately when the users requests the entitiy be associated with " +"the session (like via save() e.g.) regardless of current transactional " +"semantics. <note> <para> Hibernate was changed slightly once the implication " +"of this was better understood so that the insert is delayed in cases where " +"that is feasible. </para> </note> The underlying issue is that the actual " +"semanctics of the application itself changes in these cases." +msgstr "" + +#. Tag: para +#: portability.xml:125 +#, no-c-format +msgid "" +"Starting with version 3.2.3, Hibernate comes with a set of <ulink url=" +"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators " +"targetting portability in a much different way. <note> <para> There are " +"specifically 2 bundled <emphasis>enhanced</emphasis>generators: " +"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> " +"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </" +"listitem> </itemizedlist> </para> </note> The idea behind these generators " +"is to port the actual semantics of the identifer value generation to the " +"different databases. For example, the <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> mimics the behavior of a sequence on " +"databases which do not support sequences by using a table." +msgstr "" + +#. Tag: title +#: portability.xml:154 +#, no-c-format +msgid "Database functions" +msgstr "" + +#. Tag: para +#: portability.xml:157 +#, no-c-format +msgid "" +"This is an area in Hibernate in need of improvement. In terms of portability " +"concerns, this function handling currently works pretty well from HQL; " +"however, it is quite lacking in all other aspects." +msgstr "" + +#. Tag: para +#: portability.xml:164 +#, no-c-format +msgid "" +"SQL functions can be referenced in many ways by users. However, not all " +"databases support the same set of functions. Hibernate, provides a means of " +"mapping a <emphasis>logical</emphasis> function name to a a delegate which " +"knows how to render that particular function, perhaps even using a totally " +"different physical function call." +msgstr "" + +#. Tag: para +#: portability.xml:170 +#, no-c-format +msgid "" +"Technically this function registration is handled through the <classname>org." +"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is " +"intended to allow users to provide custom function definitions without " +"having to provide a custom dialect. This specific behavior is not fully " +"completed as of yet." +msgstr "" + +#. Tag: para +#: portability.xml:177 +#, no-c-format +msgid "" +"It is sort of implemented such that users can programatically register " +"functions with the <classname>org.hibernate.cfg.Configuration</classname> " +"and those functions will be recognized for HQL." +msgstr "" + +#. Tag: title +#: portability.xml:187 +#, no-c-format +msgid "Type mappings" +msgstr "" + +#. Tag: para +#: portability.xml:189 +#, no-c-format +msgid "This section scheduled for completion at a later date..." +msgstr "" Added: core/branches/Branch_3_3/documentation/manual/src/main/docbook/zh-CN/content/portability.po =================================================================== --- core/branches/Branch_3_3/documentation/manual/src/main/docbook/zh-CN/content/portability.po (rev 0) +++ core/branches/Branch_3_3/documentation/manual/src/main/docbook/zh-CN/content/portability.po 2009-06-23 05:46:34 UTC (rev 16878) @@ -0,0 +1,234 @@ +# Language zh-CN translations for Branch package. +# Automatically generated, 2009. +# +msgid "" +msgstr "" +"Project-Id-Version: Branch 3_3\n" +"Report-Msgid-Bugs-To: http://bugs.kde.org\n" +"POT-Creation-Date: 2009-06-16 18:47+0000\n" +"PO-Revision-Date: 2009-06-16 18:47+0000\n" +"Last-Translator: Automatically generated\n" +"Language-Team: none\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Tag: title +#: portability.xml:26 +#, no-c-format +msgid "Database Portability Considerations" +msgstr "" + +#. Tag: title +#: portability.xml:29 +#, no-c-format +msgid "Portability Basics" +msgstr "" + +#. Tag: para +#: portability.xml:31 +#, no-c-format +msgid "" +"One of the selling points of Hibernate (and really Object/Relational Mapping " +"as a whole) is the notion of database portability. This could mean an " +"internal IT user migrating from one database vendor to another, or it could " +"mean a framework or deployable application consuming Hibernate to " +"simultaneously target multiple database products by their users. Regardless " +"of the exact scenario, the basic idea is that you want Hibernate to help you " +"run against any number of databases without changes to your code, and " +"ideally without any changes to the mapping metadata." +msgstr "" + +#. Tag: title +#: portability.xml:42 +#, no-c-format +msgid "Dialect" +msgstr "" + +#. Tag: para +#: portability.xml:44 +#, no-c-format +msgid "" +"The first line of portability for Hibernate is the dialect, which is a " +"specialization of the <classname>org.hibernate.dialect.Dialect</classname> " +"contract. A dialect encapsulates all the differences in how Hibernate must " +"communicate with a particular database to accomplish some task like getting " +"a sequence value or structuring a SELECT query. Hibernate bundles a wide " +"range of dialects for many of the most popular databases. If you find that " +"your particular database is not among them, it is not terribly difficult to " +"write your own." +msgstr "" + +#. Tag: title +#: portability.xml:55 +#, no-c-format +msgid "Dialect resolution" +msgstr "" + +#. Tag: para +#: portability.xml:57 +#, no-c-format +msgid "" +"Originally, Hibernate would always require that users specify which dialect " +"to use. In the case of users looking to simultaneously target multiple " +"databases with their build that was problematic. Generally this required " +"their users to configure the Hibernate dialect or defining their own method " +"of setting that value." +msgstr "" + +#. Tag: para +#: portability.xml:64 +#, no-c-format +msgid "" +"Starting with version 3.2, Hibernate introduced the notion of automatically " +"detecting the dialect to use based on the <interfacename>java.sql." +"DatabaseMetaData</interfacename> obtained from a <interfacename>java.sql." +"Connection</interfacename> to that database. This was much better, expect " +"that this resolution was limited to databases Hibernate know about ahead of " +"time and was in no way configurable or overrideable." +msgstr "" + +#. Tag: para +#: portability.xml:72 +#, no-c-format +msgid "" +"Starting with version 3.3, Hibernate has a fare more powerful way to " +"automatically determine which dialect to should be used by relying on a " +"series of delegates which implement the <interfacename>org.hibernate.dialect." +"resolver.DialectResolver</interfacename> which defines only a single method:" +"<programlisting><![CDATA[public Dialect resolveDialect(DatabaseMetaData " +"metaData) throws JDBCConnectionException]]></programlisting>. The basic " +"contract here is that if the resolver 'understands' the given database " +"metadata then it returns the corresponding Dialect; if not it returns null " +"and the process continues to the next resolver. The signature also " +"identifies <exceptionname>org.hibernate.exception.JDBCConnectionException</" +"exceptionname> as possibly being thrown. A JDBCConnectionException here is " +"interpreted to imply a \"non transient\" (aka non-recoverable) connection " +"problem and is used to indicate an immediate stop to resolution attempts. " +"All other exceptions result in a warning and continuing on to the next " +"resolver." +msgstr "" + +#. Tag: para +#: portability.xml:85 +#, no-c-format +msgid "" +"The cool part about these resolvers is that users can also register their " +"own custom resolvers which will be processed ahead of the built-in Hibernate " +"ones. This might be useful in a number of different situations: it allows " +"easy integration for auto-detection of dialects beyond those shipped with " +"HIbernate itself; it allows you to specify to use a custom dialect when a " +"particular database is recognized; etc. To register one or more resolvers, " +"simply specify them (seperated by commas, tabs or spaces) using the " +"'hibernate.dialect_resolvers' configuration setting (see the " +"<constant>DIALECT_RESOLVERS</constant> constant on <classname>org.hibernate." +"cfgEnvironment</classname>)." +msgstr "" + +#. Tag: title +#: portability.xml:98 +#, no-c-format +msgid "Identifier generation" +msgstr "" + +#. Tag: para +#: portability.xml:100 +#, no-c-format +msgid "" +"When considering portability between databases, another important decision " +"is selecting the identifier generation stratagy you want to use. Originally " +"Hibernate provided the <emphasis>native</emphasis> generator for this " +"purpose, which was intended to select between a <emphasis>sequence</" +"emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis> " +"strategy depending on the capability of the underlying database. However, an " +"insidious implication of this approach comes about when targtetting some " +"databases which support <emphasis>identity</emphasis> generation and some " +"which do not. <emphasis>identity</emphasis> generation relies on the SQL " +"definition of an IDENTITY (or auto-increment) column to manage the " +"identifier value; it is what is known as a post-insert generation strategy " +"becauase the insert must actually happen before we can know the identifier " +"value. Because Hibernate relies on this identifier value to uniquely " +"reference entities within a persistence context it must then issue the " +"insert immediately when the users requests the entitiy be associated with " +"the session (like via save() e.g.) regardless of current transactional " +"semantics. <note> <para> Hibernate was changed slightly once the implication " +"of this was better understood so that the insert is delayed in cases where " +"that is feasible. </para> </note> The underlying issue is that the actual " +"semanctics of the application itself changes in these cases." +msgstr "" + +#. Tag: para +#: portability.xml:125 +#, no-c-format +msgid "" +"Starting with version 3.2.3, Hibernate comes with a set of <ulink url=" +"\"http://in.relation.to/2082.lace\">enhanced</ulink> identifier generators " +"targetting portability in a much different way. <note> <para> There are " +"specifically 2 bundled <emphasis>enhanced</emphasis>generators: " +"<itemizedlist> <listitem> <para> <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> </para> </listitem> <listitem> <para> " +"<classname>org.hibernate.id.enhanced.TableGenerator</classname> </para> </" +"listitem> </itemizedlist> </para> </note> The idea behind these generators " +"is to port the actual semantics of the identifer value generation to the " +"different databases. For example, the <classname>org.hibernate.id.enhanced." +"SequenceStyleGenerator</classname> mimics the behavior of a sequence on " +"databases which do not support sequences by using a table." +msgstr "" + +#. Tag: title +#: portability.xml:154 +#, no-c-format +msgid "Database functions" +msgstr "" + +#. Tag: para +#: portability.xml:157 +#, no-c-format +msgid "" +"This is an area in Hibernate in need of improvement. In terms of portability " +"concerns, this function handling currently works pretty well from HQL; " +"however, it is quite lacking in all other aspects." +msgstr "" + +#. Tag: para +#: portability.xml:164 +#, no-c-format +msgid "" +"SQL functions can be referenced in many ways by users. However, not all " +"databases support the same set of functions. Hibernate, provides a means of " +"mapping a <emphasis>logical</emphasis> function name to a a delegate which " +"knows how to render that particular function, perhaps even using a totally " +"different physical function call." +msgstr "" + +#. Tag: para +#: portability.xml:170 +#, no-c-format +msgid "" +"Technically this function registration is handled through the <classname>org." +"hibernate.dialect.function.SQLFunctionRegistry</classname> class which is " +"intended to allow users to provide custom function definitions without " +"having to provide a custom dialect. This specific behavior is not fully " +"completed as of yet." +msgstr "" + +#. Tag: para +#: portability.xml:177 +#, no-c-format +msgid "" +"It is sort of implemented such that users can programatically register " +"functions with the <classname>org.hibernate.cfg.Configuration</classname> " +"and those functions will be recognized for HQL." +msgstr "" + +#. Tag: title +#: portability.xml:187 +#, no-c-format +msgid "Type mappings" +msgstr "" + +#. Tag: para +#: portability.xml:189 +#, no-c-format +msgid "This section scheduled for completion at a later date..." +msgstr ""