example_parentchild.po

hibernate 开源框架的代码 jar包希望大家能喜欢

"    c.setParent(this);\n"
"    children.add(c);\n"
"}]]>"
msgstr ""
"<![CDATA[public void addChild(Child c) {\n"
"    c.setParent(this);\n"
"    children.add(c);\n"
"}]]>"

#: index.docbook:143
msgid "Now, the code to add a <literal>Child</literal> looks like"
msgstr ""
"Ahora, el c&#x00f3;digo para a&#x00f1;adir un <literal>Child</literal> se ve "
"as&#x00ed;"

#: index.docbook:147
msgid ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = new Child();\n"
"p.addChild(c);\n"
"session.save(c);\n"
"session.flush();]]>"
msgstr ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = new Child();\n"
"p.addChild(c);\n"
"session.save(c);\n"
"session.flush();]]>"

#: index.docbook:152
msgid "Cascading life cycle"
msgstr "Ciclo de vida en cascada"

#: index.docbook:154
msgid ""
"The explicit call to <literal>save()</literal> is still annoying. We will "
"address this by using cascades."
msgstr ""
"La llamada expl&#x00ed;cita a <literal>save()</literal> es a&#x00fa;n "
"molesta. Apuntaremos a esto usando tratamientos en cascada."

#: index.docbook:159
msgid ""
"<![CDATA[<set name=\"children\" inverse=\"true\" cascade=\"all\">\n"
"    <key column=\"parent_id\"/>\n"
"    <one-to-many class=\"Child\"/>\n"
"</set>]]>"
msgstr ""
"<![CDATA[<set name=\"children\" inverse=\"true\" cascade=\"all\">\n"
"    <key column=\"parent_id\"/>\n"
"    <one-to-many class=\"Child\"/>\n"
"</set>]]>"

#: index.docbook:161
msgid "This simplifies the code above to"
msgstr "Esto simplifica el c&#x00f3;digo anterior a"

#: index.docbook:165
msgid ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = new Child();\n"
"p.addChild(c);\n"
"session.flush();]]>"
msgstr ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = new Child();\n"
"p.addChild(c);\n"
"session.flush();]]>"

#: index.docbook:167
msgid ""
"Similarly, we don't need to iterate over the children when saving or "
"deleting a <literal>Parent</literal>. The following removes <literal>p</"
"literal> and all its children from the database."
msgstr ""
"Similarmente, no necesitamos iterar los hijos al salvar o borrar un "
"<literal>Parent</literal>. Lo siguiente quita <literal>p</literal> y todos "
"sus hijos de la base de datos."

#: index.docbook:172
msgid ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"session.delete(p);\n"
"session.flush();]]>"
msgstr ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"session.delete(p);\n"
"session.flush();]]>"

#: index.docbook:174
msgid "However, this code"
msgstr "Sin embargo, este c&#x00f3;digo"

#: index.docbook:178
msgid ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = (Child) p.getChildren().iterator().next();\n"
"p.getChildren().remove(c);\n"
"c.setParent(null);\n"
"session.flush();]]>"
msgstr ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = (Child) p.getChildren().iterator().next();\n"
"p.getChildren().remove(c);\n"
"c.setParent(null);\n"
"session.flush();]]>"

#: index.docbook:180
msgid ""
"will not remove <literal>c</literal> from the database; it will ony remove "
"the link to <literal>p</literal> (and cause a <literal>NOT NULL</literal> "
"constraint violation, in this case). You need to explicitly <literal>delete()"
"</literal> the <literal>Child</literal>."
msgstr ""
"no quitar&#x00e1; <literal>c</literal> de la base de datos; s&#x00f3;lo "
"quitar&#x00e1; el enlace a <literal>p</literal> (y causar&#x00e1; una "
"violaci&#x00f3;n a una restricci&#x00f3;n <literal>NOT NULL</literal>). "
"Necesitas borrar el hijo expl&#x00ed;citamente llamando a <literal>delete()</"
"literal>."

#: index.docbook:186
msgid ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = (Child) p.getChildren().iterator().next();\n"
"p.getChildren().remove(c);\n"
"session.delete(c);\n"
"session.flush();]]>"
msgstr ""
"<![CDATA[Parent p = (Parent) session.load(Parent.class, pid);\n"
"Child c = (Child) p.getChildren().iterator().next();\n"
"p.getChildren().remove(c);\n"
"session.delete(c);\n"
"session.flush();]]>"

#: index.docbook:188
msgid ""
"Now, in our case, a <literal>Child</literal> can't really exist without its "
"parent. So if we remove a <literal>Child</literal> from the collection, we "
"really do want it to be deleted. For this, we must use <literal>cascade="
"\"all-delete-orphan\"</literal>."
msgstr ""
"Ahora, en nuestro caso, un <literal>Child</literal> no puede existir "
"realmente sin su padre. De modo que si quitamos un <literal>Child</literal> "
"de la colecci&#x00f3;n, realmente queremos que sea borrado. Para esto, "
"debemos usar <literal>cascade=\"all-delete-orphan\"</literal>."

#: index.docbook:194
msgid ""
"<![CDATA[<set name=\"children\" inverse=\"true\" cascade=\"all-delete-orphan"
"\">\n"
"    <key column=\"parent_id\"/>\n"
"    <one-to-many class=\"Child\"/>\n"
"</set>]]>"
msgstr ""
"<![CDATA[<set name=\"children\" inverse=\"true\" cascade=\"all-delete-orphan"
"\">\n"
"    <key column=\"parent_id\"/>\n"
"    <one-to-many class=\"Child\"/>\n"
"</set>]]>"

#: index.docbook:196
msgid ""
"Note: even though the collection mapping specifies <literal>inverse=\"true"
"\"</literal>, cascades are still processed by iterating the collection "
"elements. So if you require that an object be saved, deleted or updated by "
"cascade, you must add it to the collection. It is not enough to simply call "
"<literal>setParent()</literal>."
msgstr ""
"Nota: aunque el mapeo de la colecci&#x00f3;n especifique <literal>inverse="
"\"true\"</literal>, el tratamiento en cascada se procesa a&#x00fa;n al "
"iterar los elementos de colecci&#x00f3;n. De modo que si requieres que un "
"objeto sea salvado, borrado o actualizado en cascada, debes a&#x00f1;adirlo "
"a la colecci&#x00f3;n. No es suficiente con simplemente llamar a "
"<literal>setParent()</literal>."

#: index.docbook:206
msgid "Cascades and <literal>unsaved-value</literal>"
msgstr "Tratamiento en cascada y <literal>unsaved-value</literal>"

#: index.docbook:208
msgid ""
"Suppose we loaded up a <literal>Parent</literal> in one <literal>Session</"
"literal>, made some changes in a UI action and wish to persist these changes "
"in a new session by calling <literal>update()</literal>. The "
"<literal>Parent</literal> will contain a collection of childen and, since "
"cascading update is enabled, Hibernate needs to know which children are "
"newly instantiated and which represent existing rows in the database. Lets "
"assume that both <literal>Parent</literal> and <literal>Child</literal> have "
"genenerated identifier properties of type <literal>Long</literal>. Hibernate "
"will use the identifier and version/timestamp property value to determine "
"which of the children are new. (See <xref linkend=\"objectstate-saveorupdate"
"\"/>.) <emphasis>In Hibernate3, it is no longer necessary to specify an "
"<literal>unsaved-value</literal> explicitly.</emphasis>"
msgstr ""
"Sup&#x00f3;n que hemos cargado un <literal>Parent</literal> en una "
"<literal>Session</literal>, hemos hecho algunos cambios en una acci&#x00f3;n "
"de UI y deseamos hacer persistentes estos cambios en una nueva sesi&#x00f3;n "
"llamando a <literal>update()</literal>. El <literal>Parent</literal> "
"contendr&#x00e1; una colecci&#x00f3;n de hijos y, ya que est&#x00e1; "
"habilitado el tratamiento en cascada, Hibernate necesita saber qu&#x00e9; "
"hijos est&#x00e1;n reci&#x00e9;n instanciados y cu&#x00e1;les representan "
"filas existentes en la base de datos. Asumamos que tanto <literal>Parent</"
"literal> como <literal>Child</literal> tienen propiedades identificadoras "
"generadas de tipo <literal>Long</literal>. Hibernate usar&#x00e1; el "
"identificador y el valor de la propiedad de versi&#x00f3;n/timestamp para "
"determinar cu&#x00e1;les de los hijos son nuevos. (Ver <xref linkend="
"\"objectstate-saveorupdate\"/>.) <emphasis>En Hibernate3, no es m&#x00e1;s "
"necesario especificar un <literal>unsaved-value</literal> expl&#x00ed;"
"citamente.</emphasis>"

#: index.docbook:220
msgid ""
"The following code will update <literal>parent</literal> and <literal>child</"
"literal> and insert <literal>newChild</literal>."
msgstr ""
"The following code will update <literal>parent</literal> and <literal>child</"
"literal> and insert <literal>newChild</literal>."

#: index.docbook:225
msgid ""
"<![CDATA[//parent and child were both loaded in a previous session\n"
"parent.addChild(child);\n"
"Child newChild = new Child();\n"
"parent.addChild(newChild);\n"
"session.update(parent);\n"
"session.flush();]]>"
msgstr ""
"<![CDATA[//parent and child were both loaded in a previous session\n"
"parent.addChild(child);\n"
"Child newChild = new Child();\n"
"parent.addChild(newChild);\n"
"session.update(parent);\n"
"session.flush();]]>"

#: index.docbook:227
msgid ""
"Well, that's all very well for the case of a generated identifier, but what "
"about assigned identifiers and composite identifiers? This is more "
"difficult, since Hibernate can't use the identifier property to distinguish "
"between a newly instantiated object (with an identifier assigned by the "
"user) and an object loaded in a previous session. In this case, Hibernate "
"will either use the timestamp or version property, or will actually query "
"the second-level cache or, worst case, the database, to see if the row "
"exists."
msgstr ""
"Bueno, todo eso est&#x00e1; muy bien para el caso de un identificador "
"generado, pero &#x00bf;qu&#x00e9; de los identificadores asignados y de los "
"identificadores compuestos? Esto es m&#x00e1;s dif&#x00ed;cil, ya que "
"Hibernate no puede usar la propiedad identificadora para distinguir entre un "
"objeto reci&#x00e9;n instanciado (con un identificador asignado por el "
"usuario) y un objeto cargado en una sesi&#x00f3;n previa. En este caso, "
"Hibernate bien usar&#x00e1; la propiedad de versi&#x00f3;n o timestamp, o "
"bien consultar&#x00e1; realmente el cach&#x00e9; de segundo nivel, o bien, "
"en el peor de los casos, la base de datos, para ver si existe la fila."

#: index.docbook:260
msgid "Conclusion"
msgstr "Conclusi&#x00f3;n"

#: index.docbook:262
msgid ""
"There is quite a bit to digest here and it might look confusing first time "
"around. However, in practice, it all works out very nicely. Most Hibernate "
"applications use the parent / child pattern in many places."
msgstr ""
"Hay que resumir un poco aqu&#x00ed; y podr&#x00ed;a parecer confuso a la "
"primera vez. Sin embargo, en la pr&#x00e1;ctica, todo funciona muy "
"agradablemente. La mayor&#x00ed;a de las aplicaciones de Hibernate usan el "
"patr&#x00f3;n padre / hijo en muchos sitios."

#: index.docbook:267
msgid ""
"We mentioned an alternative in the first paragraph. None of the above issues "
"exist in the case of <literal>&lt;composite-element&gt;</literal> mappings, "
"which have exactly the semantics of a parent / child relationship. "
"Unfortunately, there are two big limitations to composite element classes: "
"composite elements may not own collections, and they should not be the child "
"of any entity other than the unique parent."
msgstr ""
"Hemos mencionado una alternativa en el primer p&#x00e1;rrafo. Ninguno de los "
"temas anteriores existe en el caso de los mapeos <literal>&lt;composite-"
"element&gt;</literal>, que tienen exactamente la sem&#x00e1;ntica de una "
"relaci&#x00f3;n padre / hijo. Desafortunadamente, hay dos grandes "
"limitaciones para las clases de elementos compuestos: los elementos "
"compuestos no pueden poseer sus propias colecciones, y no deben ser el hijo "
"de cualquier otra entidad que no sea su padre &#x00fa;nico."

msgid "ROLES_OF_TRANSLATORS"
msgstr "<!--TRANS:ROLES_OF_TRANSLATORS-->"

msgid "CREDIT_FOR_TRANSLATORS"
msgstr "<!--TRANS:CREDIT_FOR_TRANSLATORS-->"