Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Done some TODOs 

git-svn-id: https://svn.jboss.org/repos/hibernate/trunk/Hibernate3/doc@5971 1b8cb986-b30d-0410-93ca-fae66ebed9b2
This commit is contained in:
Christian Bauer 2005-02-28 19:05:56 +00:00
parent a308fb5153
commit 932b9b18db
4 changed files with 14 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
reference/en/modules/example_mappings.xml
View File

@ -353,7 +353,8 @@ alter table line_items
<para>
These examples are all taken from the Hibernate test suite. You
will find many other useful example mappings there.
will find many other useful example mappings there. Have a look at the
<literal>src</literal> folder of the Hibernate distribution.
</para>
<para>TODO: put words around this stuff</para>

11
reference/en/modules/performance.xml
View File

@ -513,12 +513,9 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
<para>
A different (better?) way to avoid unnecessary column reads, at least for
read-only transactions is to use the projection features of HQL. This avoids
the need for buildtime bytecode processing.
</para>
<para>
TODO: Document issues with lazy property loading
read-only transactions is to use the projection features of HQL or Criteria
queries. This avoids the need for buildtime bytecode processing and is
certainly a prefered solution.
</para>
</sect2>
@ -1163,7 +1160,7 @@ StatisticsService stats = new StatisticsService(); // MBean implementation
server.registerMBean(stats, on); // Register the MBean on the server]]></programlisting>
<para>
TODO: This doesn't make sense. In the first case, we retrieve and use the MBean directly. In the second one, we must give
TODO: This doesn't make sense: In the first case, we retrieve and use the MBean directly. In the second one, we must give
the JNDI name in which the session factory is held before using it. Use
<literal>hibernateStatsBean.setSessionFactoryJNDIName("my/JNDI/Name")</literal>
</para>

4
reference/en/modules/session_api.xml
View File

@ -1195,13 +1195,13 @@ tx.commit(); // flush occurs]]></programlisting>
</para>
<programlisting><![CDATA[Cat fritz = ......;
Long id = (Long) catMeta.getIdentifier(fritz);
ClassMetadata catMeta = sessionfactory.getClassMetadata(Cat.class);
Object[] propertyValues = catMeta.getPropertyValues(fritz);
String[] propertyNames = catMeta.getPropertyNames();
Type[] propertyTypes = catMeta.getPropertyTypes();
// get a Map of all properties which are not collections or associations
// TODO: what about components?
Map namedValues = new HashMap();
for ( int i=0; i<propertyNames.length; i++ ) {
if ( !propertyTypes[i].isEntityType() && !propertyTypes[i].isCollectionType() ) {

12
reference/en/modules/transactions.xml
View File

@ -500,12 +500,12 @@ finally {
can occur in a Hibernate persistence layer, is an unchecked exception (it wasn't
in older versions of Hibernate). In our opinion, we shouldn't force the application
developer to catch an unrecoverable exception at a low layer. In most systems, unchecked
and fatal exceptions are only catched at the highest level of the call stack and an
error message is presented to the application user (or some other appropriate action
is taken). Note that Hibernate might also throw other unchecked exceptions (e.g.
when detecting stale data in version checks) which are not a
<literal>HibernateException</literal>. These are, again, not recoverable and appropriate
action should be taken.
and fatal exceptions are only catched in one of the first frames of the method call
stack (i.e. in higher layers) and an error message is presented to the application
user (or some other appropriate action is taken). Note that Hibernate might also throw
other unchecked exceptions (e.g. when detecting stale data in version checks) which are
not a <literal>HibernateException</literal>. These are, again, not recoverable and
appropriate action should be taken.
</para>
<para>