org.hibernate.test.cache.infinispan.functional.BasicTransactionalTestCase.testQueryCache failure
by Galder Zamarreño
Hi Steve,
The difference in behavior recently is the following: Hibernate has always treated VersionedItem and Item as two query translators for queries like "from Item". The difference is that in the past, the 2nd time a query was executed, VersionedItem query resulted on a query put whereas now it's a query hit. This leads to query hits being 2 instead of 1. 2 is probably correct if you consider VersionedItem to be an Item, which it is. In the past, VersionedItem query would have been considered a put, even the second time around and so query hit was only 1.
If you want to investigate further, simply have two entities, one extending each other and do 2 queries with "from X" where X is the top class. In 3.5.0, the first query resulted in two query puts and the second one resulted in 1 query put, 1 query hit. In trunk and 3.5.x now, the first query results in two query puts and the 2nd query in two query hits.
For my tests, I'm getting rid of this polymorphism to avoid testing stuff I don't need to be testing from an Infinispan perspective.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 2 months
Re: [hibernate-dev] Tutorial Examples
by Misty Stanley-Jones
Another possibility is including the .zip in the document bundle (for non-PDF document targets, at least). Publican can handle this by putting the .zip in a files/ subdirectory and using a <ulink> to its relative location. This is one way to have a 1:1 relationship between the doc version and the .zip version.
----- hibernate-dev-request(a)lists.jboss.org wrote:
> From: hibernate-dev-request(a)lists.jboss.org
> To: hibernate-dev(a)lists.jboss.org
> Sent: Saturday, August 28, 2010 2:00:05 AM GMT +10:00 Brisbane
> Subject: hibernate-dev Digest, Vol 50, Issue 13
>
> 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. Tutorials (Steve Ebersole)
> 2. Re: Tutorials (Emmanuel Bernard)
> 3. Re: Tutorials (Steve Ebersole)
> 4. Re: Tutorials (Hardy Ferentschik)
> 5. Re: Tutorials (Steve Ebersole)
> 6. Re: Tutorials (Steve Ebersole)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 26 Aug 2010 13:21:12 -0500
> From: Steve Ebersole <steve(a)hibernate.org>
> Subject: [hibernate-dev] Tutorials
> To: hibernate-dev(a)lists.jboss.org
> Message-ID: <1282846872.12095.12.camel@apollo>
> Content-Type: text/plain; charset="UTF-8"
>
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5441
>
> There was a suggestion to externalize all the tutorial source into a
> separate zip to make it even easier to get started. So as a user I'd
> be
> able to download the tutorials.zip (with or without the "getting
> started
> guide"), extract it and be up and running. The actual documentation
> would then not have to have the contents of all these files in total,
> which help cut down on the size as well, though might make it not as
> easy to follow, not sure.
>
> Curious what y'all thought about this based on other tutorial sets
> you
> have run across and used.
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
>
>
>
--
Misty Stanley-Jones
Content Author, ECS Brisbane
Ph: +61 7 3514 8105
RHCT #60501081553354
Purgamentum init, exit purgamentum.
14 years, 2 months
Tutorials
by Steve Ebersole
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5441
There was a suggestion to externalize all the tutorial source into a
separate zip to make it even easier to get started. So as a user I'd be
able to download the tutorials.zip (with or without the "getting started
guide"), extract it and be up and running. The actual documentation
would then not have to have the contents of all these files in total,
which help cut down on the size as well, though might make it not as
easy to follow, not sure.
Curious what y'all thought about this based on other tutorial sets you
have run across and used.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 2 months
Status of XML mapping feature?
by Antoine Roux
Hi,
On a new project, we are thinking of using the XML mapping feature for
working with persistent XML data. I saw in the documentation that this
feature is still experimental.
What is its status? Do you know when it is going to be officially released?
Do you think there will still be changes in the API? Is it stable enough
that we can start working with it?
Thank you for information.
Antoine
14 years, 3 months
hibernate-mapping DTD as XSD
by Steve Ebersole
Any objections to either converting to XSD completely or publishing in
both formats?
What I'd really like is to be able to parse and validate a mapping
document in separate steps. The validation would come from
javax.xml.validation package. However that package does not support
DTD, only XSD. That is because currently we do not know whether a
document we are trying to parse is a Hibernate hbm.xml document, a JPA 1
orm.xml document or a JPA 2 orm.xml document. Ideally I'd like to parse
it and apply validations, possibly based on peeking at the document.
Additionally this would allow better control over enabling/disabling
schema validation.
Anyone recommend a good DTD -> XSD tool?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 3 months
On Hibernate Search and non Public API use of Core and other SNAPSHOT concerns
by Emmanuel Bernard
This is a follow up on IRC's discussion between Steve and Sanne spawned by http://in.relation.to/Bloggers/SimultaneousHibernate355And360Beta3Release...
Since I wasn't there and now you are all gone, I'm using email :)
Here is my opinion
* Hibernate Search should not depend on non public Hibernate Core APIs
HSearch is aimed at working with other backends in the medium run (does this expression exist?). So we should isolate Hibernate Core use of public APIs and certainly not use non public APIs.
Let's code move SoftLimitMRUCache, into HSearch codebase http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-580
( on a side note, SoftLimitMRUCache could be considered a public API as it is referenced in a public API JavaDoc (Environment) )
Also the use of org.hibernate.util.StringHelper in HSearch is wrong. We have org.hibernate.annotations.common.util.StringHelper
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-581
* Hibernate Search should not use third-party SNAPSHOT dependencies (including Core)
Using snapshots makes the build non reproducible (snapshots go away) and we did lose close to a collective day of work on such issue not so long ago when HSearch was depending on Core 3.6.0-SNAPSHOT
* what to do for Core 3.6 and HSearch
We should release v 3.3 beta 1 (see a previous email on mine on documentation). I will spend some cycles on this.
* How to prevent such problem in the future
Good question.
Follow rules above :)
Sanne's idea of having some integration (hudson) job specifically altering Core version to the SNAPSHOT scheme in HSearch's pom seems to work if Core publishes snapshots regularly. I am not sure if this can be trivially set up though.
Ideally, right before a final Core release (including micro points), we should test the expected HSearch version with it (for example Core 3.5.x with HSearch 3.2.x latest) but that's a manual step to add on a long list of manual steps. Not sure that's viable.
PS: These rules are even truer (SIC) for Hibernate Validator but HV 4 has been a better citizen
14 years, 3 months
