Length of test methods
by Hardy Ferentschik
Hi,
looking at some metamodel test code today I found a test method 'doTest' w/ 200 lines of code and countless assertions
of the form 'assertTrue/False(condition)', 'assertEquals(expected, actual)'.
I am having several problems with this type of testing:
* test method should be descriptive, for example testForeignKeyBindingManyToOne, testBagBinding, testSetBinding, …
* test method should be short and in a perfect case one make a couple of assertions per test (then you often don't even
need much comments, because the test name directly hints to what you are testing). Rather repeat some setup code
in each method than asserting EVERYTHING there is to a EntityBinding (as example)
* Avoid assertTrue/False. assertEquals has a much more helpful message if things fail. If you use assertTrue/False add
a message about your expectation
* Add assertion messages (also for assertEquals)
Why do I care? Once the code breaks you need at a first step understand what actually gets tested and that is easier with
short descriptive methods and assertion messages.
--Hardy
13 years, 11 months
brainstorming hibernate search integration Solr
by Gustavo Candela
Hi all,
Lately i have been thinking about integrating Hibernate Search with Solr.
What i would like to have is Solr using Hibernate Search indexes. I could
not start the implementation because i am working in other things at this
moment. I would like to know any references or ideas....
I don't know if HS puts some metainformation in the indexes and solr can
not read them....i also think that i have to create an schema in solr with
the index fields...
I am working on a very important project using hibernate search as
persistence. My boss asked about this question last week and i decided to
google it a little bit. You can find the post that i wrote here:
https://forum.hibernate.org/viewtopic.php?f=9&t=1015540
Thanks everybody,
Hibernator,
13 years, 11 months
JPA 2.1
by Steve Ebersole
I spent yesterday getting the JPA API project set up for version 2.1 and
bringing the code up-to-date up through the latest draft (Draft 6).
Feel free to peruse the code and point out anything I might have missed
: https://github.com/hibernate/hibernate-jpa-api
As a side note, that hibernate-jpa-api project is the first time ever I
have been successful at using IntelliJ's built in "import Gradle
project". I used IntelliJ 11.1.2 and Gradle 1.0-milestone-8a. Seems
like that is finally moving in a good direction based on my experiences,
which is great!
--
steve(a)hibernate.org
http://hibernate.org
13 years, 11 months
metamodel work
by Steve Ebersole
Just a heads up of a few things for those of us working on the metamodel
branch.
1) I just added the ability to have legacy-style HBM mappings parse
properly using the JaxbHelper. This is awesome because it allows us to
keep the test mappings as-is for the time being and use them in both the
older Configuration approach or the new metamodel approach, which is
awesome in conjunction with...
2) Better passing of command-line system props to tests. I changed the
gradle script a little bit to pass any command line argument system
property (-D) that starts with 'hibernate.' along to the process used to
run the tests. So now, for example, specifying
`-Dhibernate.test.new_metadata_mappings=true` on the gradle command line
actually gets that setting passed along to the tests as a system property.
3) Maybe this is useful in testing, maybe it isnt but a related change
made along with (1) was the ability to disable XML validation. The
setting that controls this is 'hibernate.xml.validate' (default = true).
Next week I will start focusing on running the full test suite using the
new_metadata_mappings settings enabled and start working on the "gaps" I
find.
--
steve(a)hibernate.org
http://hibernate.org
13 years, 11 months
Hibernate OGM: organize JIRA issues in components?
by Sanne Grinovero
I'm tempted to create different components for each datastore, so we
can easily classify them and search for areas:
- ehcache
- infinispan
- mongodb
- cassandra
useful to understand the progress per area.. we can later add more components.
Alternative, we could use labels.. but they are often too flexible,
while in this case a single category is often a good fit.
comments before I proceed?
It's good for me to go through them, I just realized my mail filters
were wiping out all changes I wasn't directly related with (unlike
with Search) and I had no idea of some issues I'm seeing open now :-/
Cheers,
Sanne
13 years, 11 months
Jira issues gone!?
by Hardy Ferentschik
Hi,
what's up with https://hibernate.onjira.com?
There projects are there, but no issues? I think we were going to upgrade Jira version, right?
Are we still in some sort of intermediate state or what is going on?
--Hardy
13 years, 11 months
Problems switching tests between old Configuration metadata and new metamodel
by Gail Badner
I'm running into 2 problems:
1) I'm not able to run the same test using both types of metadata using the new=style <hibernate-mapping>:
<hibernate-mapping package="org.hibernate.test.ops"
xmlns="http://www.hibernate.org/xsd/hibernate-mapping"
xsi:schemaLocation="http://www.hibernate.org/xsd/hibernate-mapping
hibernate-mapping-4.0.xsd"
xmlnssi="http://www.w3.org/2001/XMLSchema-instance">
I've tried using -Dhibernate.xml.validate=false, but I get:
org.hibernate.testing.junit4.CallbackException: org.hibernate.testing.junit4.BaseCoreFunctionalTestCase#buildSessionFactory
...
Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'hibernate-mapping'.
...
I can change my tests to use the old header for now. I was just wondering if this was expected to work now.
2) It is not possible to override the setting for hibernate.test.new_metadata_mappings using an environment variable if it's already set explicitly in the test's configure(). I thought this was possible with other properties in the past, but maybe not.
Basically, I override BaseCoreFunctionalTestCase.configure() and add:
cfg.setProperty( USE_NEW_METADATA_MAPPINGS, "true");
for tests that should use the new metamodel by default when "gradle test" is used.
In addition, I'd like to be able to execute the test using the Configuration metadata by overriding using -Dhibernate.test.new_metadata_mappings=false.
Should this be possible?
Gail
13 years, 11 months
[OGM] Hibernate version used in OGM
by Pawel Kozlowski
Hi!
I wonder if there are any plans to bump up Hibernate version used by
OGM to 4.1.x (from the 4.0.1) currently used?
I'm asking since - while playing with Neo4j integration - I'm bumping
into https://hibernate.onjira.com/browse/HHH-7147.
Of course the work-around is easy but it needs to be done in each and
every dialect (I can see the 'started' flag in Infinispan,
isCacheStarted in MongoDB while no-work-around in EhCache).
I don't know how much has changed from 4.0.1 till 4.1.2 so don't know
how hard / easy bumping up Hiernate's version would be...
Cheers,
Pawel
13 years, 11 months
Multi-Tenancy and "shared" data
by Steve Ebersole
Multi-tenant setups sometimes have data that is shared between the
tenants (codec tables, etc).
I think the first question is do we want to support this mixing? I
think it is common enough that it is worthwhile to support it. And I do
not think it is complicated enough to be painful to implement. As long
as we assume that there is some form of database-level availability
between shared, non-shared data (even for the DATABASE and SCHEMA
strategies) I think we will be fine.
Assuming we do support it, there is a decision we need to make about how
we differentiate shared (tenant aware) and non-shared (non-tenant aware)
data, especially important when we talk about the DISCRIMINATOR approach
which touches on a more general outstanding decision with regard to
supporting DISCRIMINATOR multi-tenancy. Basically whether entities are
inclusively considered multi-tenant when the user has specified
DISCRIMINATOR, or whether we expect some form of annotation stating the
entity is multi-tenant. Personally, I think the inclusive approach (all
entities are assumed multi-tenant) is probably the better approach. In
which case we need an annotation to say "this entity is not multi-tenant".
--
steve(a)hibernate.org
http://hibernate.org
13 years, 11 months
