On 15/04/15 15:20, Gunnar Morling wrote:
> umm, the point is that @SkipByGridDialect doesn't work, or
I could
just put it on existing methods.
By splitting up the affected tests into several classes you should be
able to apply @SkipByGridDialect on the class level. Then no session
factory at allwill be built bootstrapped for a skipped backend.
hmm, something fishy there - I recall trying that and finding it didn't
work as the creation was still done before the annotation processing.
That was a while back though and I may have fallen foul of the
interesting issues where the test class that's actually used is the one
from the last build in the mvn repo, not the current source in the core
module. I'll give it another try, since it's certainly an attractive
path forward if it does work.
So you should be fine if you manage to cut affected tests into pieces
(classes) which either require an entity not processable by Cassandra
(then exclude that test class via @SkipByGridDialect) or which require
only entities processable by Cassandra (then you still could apply
@SkipByGridDialect on the method-level to skip specific methods due to
reasons other than the reading of the entities themselves).
>Not sure I like the ongoing cognitive load of having two different
strategies for test exclusions, but it's certainly less engineering
effort than adding support for method level POJO usage declarations.
Right, I would not like that either. Also exclusions in the POM won't
apply when e.g. running all tests of a module in your IDE. The mechanism
should solely based on the OGM test runner.
2015-04-15 15:53 GMT+02:00 Jonathan Halliday
<jonathan.halliday(a)redhat.com <mailto:jonathan.halliday@redhat.com>>:
On 15/04/15 13:54, Gunnar Morling wrote:
How many tests are affected by this problem?
hmm, good question. At present most of the association tests and a
handful of assorted others that happen to use associations are
blowing up because I haven't finished the association support. I'm
working through them gradually, resolving the legit failures and
excluding the one that can't be expected to ever work. My feeling
so far is that it will affect maybe 5-10 test classes, which for
refacoring purposes is a more important count than number of test
methods.
If not too many, it might be feasible to split those test
methods into
several test classes (each only referencing the entities it actually
needs) which you then can mark individually with
@SkipByGridDialect as
needed.
umm, the point is that @SkipByGridDialect doesn't work, or I could
just put it on existing methods. However that's a moot point, since
if it's refactored to a separate class I can exclude it by class
name in the pom. Not sure I like the ongoing cognitive load of
having two different strategies for test exclusions, but it's
certainly less engineering effort than adding support for method
level POJO usage declarations.
I am no big of copying/pasting tests to the backend, we
generally aim
for having as many tests in the TCK as possible. Only tests for
store-specific features or the persistent format should be in the
backends whenever possible. Sub-classing might work, though I
find it
not as nice to work with, as it requires you to look/edit at two
places
when working with a given test (we have some tests which use that
pattern for MongoDB). I also would prefer to not change semantics of
existing tests.
I like the idea of a @TestEntities(Entity1.class, Entity2.class)
annotation which allows to specify the required entity types per
test
class and/or method (probably cumulative, if given at both
levels). This
would be my preference if splitting up doesn't work.
Can you name an example of a test affected by this?
Basket.java: @OneToMany List<Product> from ManyToOneTest
2015-04-15 13:41 GMT+02:00 Jonathan Halliday
<jonathan.halliday(a)redhat.com
<mailto:jonathan.halliday@redhat.com>
<mailto:jonathan.halliday@__redhat.com
<mailto:jonathan.halliday@redhat.com>>>:
In the course of developing the cassandra backend for OGM
I've hit an
issue with some of the backendtck tests.
These tests are in core and reused by each backend. It's
possible to
exclude tests at class or method level per backend, which
prevents
irrelevant tests from running for a given backend. So far,
so good.
The problem I'm seeing stems from the fact that even when a
test is
excluded, the annotated POJOs it uses are still parsed and
passed
through schema creation, since that occurs in a setup step
before the
individual tests are iterated and (not) run.
There are certain POJOs that contains mappings cassandra
can't support.
Even with the corresponding test disabled, when these are
passed to the
schema creator it blows up, effectively preventing the
other legitimate
tests in the same class from running.
In an ideal world I'd like a class/method level annotation
listing the
required POJOs to replace the getAnnotatedClasses method,
allowing POJOs
to be parsed or skipped in accordance with the
corresponding annotation
on the same test method.
@RequiredPOJO(Foo.class)
@Test
@SkipByGridDialect(...)
public void testFoo()
Alternatively I can (I think) subclass the test class in
the backend and
override the getAnnotatedClasses method to exclude the
problem POJOs,
whilst leaving the @SkipByGridDialect on the shared parent
for clarity.
Or simply copy and paste the whole thing and nuke the
offending
POJOs/methods in my backend's copy.
On a related note, many of the offending tests could be
altered in such
a way that the resulting schema is acceptable to cassandra,
which would
largely sidestep the issue but alter the test semantics. In
many
instances I suspect the semantic in question is one that's
not critical
to the test's intent, but I may be wrong.
Essentially cassandra uses what a relational db would call
'index
organized tables', i.e. the on-disk layout of data is a
function of the
table's key. As a result, it's not possible to declare
tables without a
primary key. Such mappings result from collections with bag
semantics,
such as @OneToMany List<Object>, since the list may have
dups. Removing
the bag semantics such as by adding an index column, avoids
this issue.
But then you're testing something different...
Any preference on the approach to changing the test suite?
Jonathan.
--
Registered in England and Wales under Company Registration No.
03798903 <tel:03798903> <tel:03798903 <tel:03798903>>
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)
_________________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
<mailto:hibernate-dev@lists.__jboss.org
<mailto:hibernate-dev@lists.jboss.org>>
https://lists.jboss.org/__mailman/listinfo/hibernate-dev
<
https://lists.jboss.org/mailman/listinfo/hibernate-dev>
--
Registered in England and Wales under Company Registration No.
03798903 <tel:03798903> Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)