How about starting a new set of tests written in the better style, and
when ready and stable, junk the old ones. Time has overtaken the old
tests and rather than change-in-place, it's sometimes easier to rewrite
with the new needs in mind.
The new framework needs to work for dataset transactions and it would be
good to get review by all organisations who extend at his point.
Andy
On 15/08/13 11:30, Mike Grove wrote:
I did not open one, no. It was not clear to me that it was a defeat,
rather than something by design that was just not optimal for what I need.
Thanks.
Mike
On Thu, Aug 15, 2013 at 6:28 AM, Claude Warren <[email protected]> wrote:
Is there a defect open for this? If so I will work on it this week. If
not I'll open one. I did a quick look and could not find it.
Claude
On Wed, Aug 7, 2013 at 5:20 PM, Mike Grove <[email protected]> wrote:
On Sun, Aug 4, 2013 at 4:46 AM, Claude Warren <[email protected]> wrote:
@Before and @After might be usable, but @BeforeClass and @AfterClass
will
not as the model is not available until the class is constructed.
I was leaning towards solution #4 myself.
This would be my preference as well, I think then overriding the tests in
the same manner as Claude has done will just work.
Cheers,
Mike
Anybody else care to weigh in?
On Sun, Aug 4, 2013 at 9:39 AM, Andy Seaborne <[email protected]> wrote:
On 01/08/13 22:18, Claude Warren wrote:
Mike poses an interesting question.
Should we add transaction boundaries to all the tests? I think
there
are
3
choices:
1) do not add transactions and developers like Mike will have
problems
with
environments that require transactions.
Can't @Before and @After (@BeforeClass, @AfterClass) be used by an
inheriting class?
2) add a switch that allows transactions to be enabled for the test
and
have the TestingModelFactory specify if it is on or off.
3) turn on transactions in the tests by default. The assumption
here
is
that all Model implementations will support the transaction calls.
But they don't!
4) use the Model.supportsTransactions() method to determine if the
transaction should be used within the test.
I would lean toward 3 or 4.
Claude
Transactions are on datasets. Models are either free standing or a
view
of a dataset. They will have different characteristics.
Fuseki adds a parallel "Transactional" object for in-memory data that
provides MRSW concurrency. That can be added to in-memory datasets
by
default if there is any demand for it.
[ Aside:
The Model interface has the begin() style transactions, which lead to
issues of lock promotion, which in turn result in the possibility of
the
system having to abort transactions because of lock
incompatibilities.
That's why datasets provide begin(read/write) -- no lock promotion
issues,
true parallel multiple-reader-single-writer, and fully serializable
transactions.
]
I wonder if there is a "Jena3" thing here to go back and review the
transaction contract and get the API sorted out if necessary. I'm
not
sure
applications working on models from datasets get the best contract
currently.
Andy
--
I like: Like Like - The likeliest place on the web<
http://like-like.xenei.com>
Identity: https://www.identify.nu/[email protected]
LinkedIn: http://www.linkedin.com/in/claudewarren
--
I like: Like Like - The likeliest place on the web<
http://like-like.xenei.com>
Identity: https://www.identify.nu/[email protected]
LinkedIn: http://www.linkedin.com/in/claudewarren
