Dialect support for SQL comments.
by Daniel Bell
Hi,
I have recently tried turning on SQL comments in hibernate 3.2.6.ga.
However, I found that our database (informix 7.31) did not support SQL
where the comment was at the start of the comment. Instead, the comment
needed to be after the SQL. For example:
/* not accepted by informix 7.31*/ select * from systables;
select * from systables /* accepted by informix 7.31*/
Because of this, I have added a method to the Dialect for adding comments:
/**
* Add a comment to the SQL string.
*
* @param sql StringBuffer holding the SQL.
* @param comment Comment to add to the SQL. May be null.
*/
public void addCommentToSql(StringBuffer sql, String comment) {
if (StringHelper.isNotEmpty(comment))
sql.insert(0, "/* " + comment + " */ ");
}
Thus, the default implementation provides the same functionality as
before. However, derived Dialects may override this method to add the
comment in a different location.
It is also possible to add additional comments in the derived Dialect.
In our case, we also add the Java thread ID.
I have included a complete patch for this change for hibernate 3.2.6.GA.
Please consider its inclusion in Hibernate.
Thanks,
Daniel.
15 years, 7 months
interesting issues in the forum
by Sanne Grinovero
hi Hardy,
I've been browsing the forums today and found these topics of interest,
they could be quite important bugs we should fix:
not working correctly with Spring (needs some test, I don't trust this
report 100%)
http://forum.hibernate.org/viewtopic.php?t=988828
memory leak on redeploy (quite good information here, but this is
going to be hard)
http://forum.hibernate.org/viewtopic.php?p=2400319
sort + scrollableresult appears to load all in memory (never happened
to me, needs a test)
http://forum.hibernate.org/viewtopic.php?t=992342
I never used Spring, so can't help there.
I have no idea about how to solve the ThreadLocal problem: this has to do with
how Hibernate registers eventlisteners and we probably should ask for
changes there
Nnot sure if we can change the EM listeners without changing the spec??
I'm absolutely no expert on other Hibernate modules.
I could try to reproduce the scrollableresult problem, but not this week.
16 years
HHH-3627 - Should concat convert parameters to string?
by Juraci Costa
All,
I don't know if this was discussed before (I didn't find it in the list's archives), but if so, I'm probably missing something basic here :-)
I came across this issue, and I don't know whether this should be changed or not. The problem is that the guy is trying to use the concat function with numeric literals. Hibernate not only accepts these values, but sends them "as is" to the RDBMS's, causing an error for MSSQL when mixing the types, or causing unexpected behaviour when using only numeric types
s.createQuery( "from Human h where h.nickName = concat(1,2)" ).list();
s.createQuery( "from Human h where h.nickName = concat(1,2,'c')" ).list();
Results in:
human0_.nickName=(
1+2 // becomes "3", instead of 12
)
and
human0_.nickName=(
1+2+'c' // error in MSSQL
)
I realize that the numeric parameters needs a cast to behave correctly, but I'm wondering if this cast should be in Hibernate or in the user's code. There are some arguments for both sides.
In Hibernate because:
- The HQL should be the same for as many RDBMS's as possible (that's one of the benefits of having a specific query language, right?). If Hibernate accepts integer parameters for "string concatenation"[1], it should do what is expected (concatenate strings)
- Both the concat and the || operator are clearly supposed to act on character types, but the MSSQL operator (+) can be used in both numeric and character types, with different purposes (arithmetic for numbers, concatenation for character). As Hibernate was asked to "concatenate", it should make this intention clear to the underlying RDBMS. In this case, by converting the values to character types. There is no such problems in other RDBMSs, as they have specific operators (||) or functions (concat) to this purpose.
- org.hibernate.dialect.function.DerbyConcatFunction seems a good precedent for such specific things :-)
In the Application because:
- As the RDBMS can accept other values than the "default string" type (varchar), the app developer should explicitly cast to the desired type, if this format is not a character type.
[1] http://www.hibernate.org/hib_docs/reference/en/html/queryhql-expressions....
So, should concat convert parameters to string?
- Juca.
16 years
Which branches should receive patches
by Juraci Costa
All,
I'm about to making some patches to fix tests which uses table/column names which are keywords for some RDBMS's. So, which branches should I target to, when making such patches?
My initial list (for trunk, but similar ones for ANN/EM):
trunk
Branch_3_2
Branch_3_2_4_SP1_CP
Should I include Branch_3_3, if applicable? Regarding Branch_3_3, I noticed it doesn't contains ANN/EM, and ANN/EM doesn't have a Branch_3_3. So, where should I take ANN/EM from, if building core from Branch_3_3 ?
- Juca.
16 years
Anyone having problems in "tutorials" module?
by Juraci Costa
All,
Hudson jobs for trunk are failing due to a dependency missing:
Path to dependency:
1) org.hibernate:hibernate-tutorials:pom:3.4.0-SNAPSHOT
2) org.slf4j:jcl-over-slf4j:jar:1.4.2
I got this error on my local setup too, when building the tutorials module. I changed the pom.xml to use jcl-over-slf4j version 1.5.2 instead of 1.4.2, and it is working again. It seems that the version 1.4.2 doesn't exists anymore in maven repository:
http://repo1.maven.org/maven2/org/slf4j/jcl-over-slf4j/
Am I the only one who faced this? Is changing this version the way to go? If so, I can open a JIRA for it and commit my changes.
- Juca.
16 years
Search: change in BackendQueueProcessorFactory public interface.
by Sanne Grinovero
Hi,
there's another urgent reason to change BackendQueueProcessorFactory:
To finish HSEARCH-268 I only need to shutdown the executors created
during initialize();
there is no stop() or shutdown() method; I am not having a way to
cleanup similar and opposite to initialize()
my patch is working well until application shutdown: JVM will stay
waiting forever;
more details on JIRA soon.
Sanne
16 years
RE: scrollableresult OOM problem
by John Griffin
I've dealt with this problem but only from an Oracle perspective. Using a
FORWARD_ONLY ScrollMode only allows the rs.next() method call. Any other
result set record movement method call results in an exception. This allows
JDBC to fetch x amount of records (set by fetch size) and then get the next
fetch size etc. This prevents caching of previously fetched records (causing
OOM with large result sets).
Since it is my understanding that Oracle sorts results and generates
a cursor on the server side, if this really is a problem, somewhere in the
code we are caching results.
The only way I have been able to scroll extremely large results is
to implement paging. This does not imply that there is state maintained. An
array of record pointers can do it and there are probably more ways.
I have no way to test this at home and I'm here all week.
My two cents.
John G.
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of
hibernate-dev-request(a)lists.jboss.org
Sent: Monday, November 24, 2008 10:00 AM
To: hibernate-dev(a)lists.jboss.org
Subject: hibernate-dev Digest, Vol 29, Issue 16
Send hibernate-dev mailing list submissions to
hibernate-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/hibernate-dev
or, via email, send a message with subject or body 'help' to
hibernate-dev-request(a)lists.jboss.org
You can reach the person managing the list at
hibernate-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hibernate-dev digest..."
Today's Topics:
1. interesting issues in the forum (Sanne Grinovero)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Nov 2008 17:17:58 +0100
From: "Sanne Grinovero" <sanne.grinovero(a)gmail.com>
Subject: [hibernate-dev] interesting issues in the forum
To: "Hardy Ferentschik" <hibernate(a)ferentschik.de>
Cc: Hibernate Dev <hibernate-dev(a)lists.jboss.org>
Message-ID:
<50e5f6250811240817qf3a9f0v84c40b5ae771e3d0(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
hi Hardy,
I've been browsing the forums today and found these topics of interest,
they could be quite important bugs we should fix:
not working correctly with Spring (needs some test, I don't trust this
report 100%)
http://forum.hibernate.org/viewtopic.php?t=988828
memory leak on redeploy (quite good information here, but this is
going to be hard)
http://forum.hibernate.org/viewtopic.php?p=2400319
sort + scrollableresult appears to load all in memory (never happened
to me, needs a test)
http://forum.hibernate.org/viewtopic.php?t=992342
I never used Spring, so can't help there.
I have no idea about how to solve the ThreadLocal problem: this has to do
with
how Hibernate registers eventlisteners and we probably should ask for
changes there
Nnot sure if we can change the EM listeners without changing the spec??
I'm absolutely no expert on other Hibernate modules.
I could try to reproduce the scrollableresult problem, but not this week.
------------------------------
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
End of hibernate-dev Digest, Vol 29, Issue 16
*********************************************
16 years
exposing statistics easier (HHH-3593 solution)
by John Mazzitelli
I recently added support to Jopr, The JBoss management platform project
( http://www.jboss.org/jopr ) to be able to monitor Hibernate via the
Hibernate Statistics MBean.
For background, see my blog entry:
http://management-platform.blogspot.com/2008/11/monitoring-hibernate.html
and more specifically, see the demo flash:
https://docs.jbosson.redhat.com/confluence/display/JON2/Demo-MonitoringHi...
If you watch that demo, you can see how useful the Hibernate Statistics
data can be (e.g. when used by external management tools like Jopr you
can track the performance of Hibernate over time, send alerts based on
that performance data, etc. etc.).
But for users to be able to monitor their Hibernate applications from an
external management tool, it isn't enough for them to specify the
"hibernate.generate_statistics" configuration setting. They must expose
those statistics via JMX; however, that puts a burden on the Hibernate
developer to write special code to do this (as the example code in the
blog illustrates - see Max's comments on my blog and my responses also).
Out of that, I submitted this JIRA:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3593
Last night I wrote the code that implements this enhancement request and
attached the patch to that JIRA. The short of it is, the Hibernate
developer no longer has to write any Java code to expose the statistics
via JMX, all you have to do is set these configuration settings:
hibernate.generate_statistics.jmx=true
hibernate.generate_statistics.jmx.object_name=hibernate:type=statistics,application=foo
hibernate.generate_statistics.jmx.mbeanserver=*platform*
If you set those, statistics generation will be turned on, the Hibernate
Statistics MBean will be exposed via JMX and if you enabled the VM for
remote JMX, you can immediately begin to monitor Hibernate (you'll even
see the Hibernate MBean via jconsole, though things like Jopr will
provide better functionality like viewing historical stat data, alerting
and the like).
As the JIRA mentions, this patch does NOT introduce any JMX compile-time
dependencies (due to the requirement that Hibernate be able to support
JDK 1.4). Therefore, you will not see any "javax.management.*" imports
or classes being used directly (they are used via reflection). However,
if you enable this JMX statistics feature, obviously, you must run in
JRE 5+ or JRE 1.4 + JMX libraries - if you do not, this code will log
error messages saying what the problem is and simply disable the JMX
stats capability (but otherwise, hibernate works normally).
Any suggestions how I might further this along to get it merged? Or is
this patch good enough for some Hibernate developer to merge it in and
take it over?
John Mazz
16 years
[Search] making updates to the indexes concurrently
by Sanne Grinovero
Hello,
because of HSEARCH-268( optimize indexes in parallel ) but also for
other purposes, I am in need to define a new ThreadPool in Hibernate
Search's
Lucene backend.
The final effect will actually be that all changes to indexes are
going to be performed in parallel (on different indexes).
I consider this a major improvement, and is currently easy to
implement, iff we solve the following problems.
The question is about how to size it properly, and how should the
parallel workers interact, especially regarding commit failures and
rollbacks:
about the size
=========
I've considered some options:
1) "steal" the configuration setting from BatchedQueueingProcessor,
transforming that implementation in singlethreaded,
and reusing the parameter internally to the Lucene backend only (JMS
doesn't need it AFAIK).
I'm afraid this could break custom made backends configuration parsing.
2)add a new parameter to the environment
3)use a size equal to the number of DirectoryProviders (this is the
optimal value, could be the default and be overriden by a parameter).
4)change the contract of BackendQueueProcessorFactory: instead of
returning one Runnable it returns a list of Runnables,
so it's possible to use the existing Executor.
This needs some consideration about how different Runnables have to
"join the same TX"; The JMS implementation could return just one
Runnable, so no worry about that.
about transactions
============
As you know Search is not using a two phase commit between DB and
Index, but Emmanuel has a very cool vision about that: we could add
that later.
The problem is: what to do if a Lucene index update fails (e.g. index
A is corrupted),
should we cancel the tasks going to make changes to the other indexes, B and C?
That would be possible, but I don't think that you like that: after
all the database changes are committed already, so I should actually
make a "best effort" to update all indexes which are still working correctly.
Another option would be to make the changes to all indexes, and then
IndexWriter.commit() them all after they are all done.
This is the opposite of the previous example, and also more complex to
implement.
I personally don't like this, but would like to hear more voices as it
is an important matter.
I think Search should work on a "best effort" criteria for next
release: update all indexes it is able to.
In a future one we could add an option to make it "two phase"
optionally) by playing with the new
Lucene commit() capabilities, but this would only make sense if you
actually wanted to rollback
the database changes in case of an index failure.
sharing IndexWriter in batch mode
=====================
this is not needed for HSEARCH-268( optimize indexes in parallel ) but
is needed to get a major boost in indexing performance.
Currently the IndexWriter lifecycle is coupled to the operations done
in a transaction; (also Emmanuel reminded me
we need to release the file lock ASAP as a supported configuration is
to use two Search instances sharing the same FS-based index).
We already have the concept of "batch operation" and "transactional
operation"; the only difference is currently about
which tuning settings are applied to the IndexWriter.
My idea is to extend the semantics of "batch mode" to mean a state
which is globally affecting the way IndexWriters
are aquired and released: when in batch mode, the IndexWriter is not
closed at the end of each work queue, and the locks are not used:
the IndexWriter could be shared across different threads. This is not
transactionally safe of course, but that's why this is called
"batch mode" opposing to "transactional mode": nobody would expect
transactional behaviour.
There should be taken care to revert the status to "transaction mode"
and close the IndexWriter at the end, but this API
would make me reindex the database using the "parallel
scrollableresults" in the most efficient way, and nicely integrated.
This isn't as complicated to implement as it is to explain;-)
Sanne
16 years
