You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Mike Grove <mi...@clarkparsia.com> on 2013/08/01 18:09:49 UTC
Re: compliance test suite?
I'm just getting back to this, thanks for the pointers. Thanks to Claude's
references, I got the Model & Graph tests patterns off his usage running
and I fail most of them since it looks like most if not all changes to the
Model/Graph are made sans-transaction.
I took a brief look at the code, and it did not seem like there was a bit
flipped that would enable them for tests. I can put autoCommit type
functionality into the code if need be, but that seemed less than ideal.
Thanks.
Mike
On Mon, Mar 25, 2013 at 11:00 AM, Andy Seaborne <an...@apache.org> wrote:
> Michael,
>
> Most of the testing gets done on the graph-level object, Model and Dataset
> are just wrapper, Dataset particularly is quite a thin wrapper. That, and
> a lot of the coverage is by being used in other places.
>
> com.hp.hpl.jena.sparql.core.**AbstractTestDataset
> com.hp.hpl.jena.sparql.core.**AbstractDatasetGraphTests
>
> com.hp.hpl.jena.graph.test.**AbstractTestGraph
> com.hp.hpl.jena.sparql.graph.**AbstractTestGraph2
>
> com.hp.hpl.jena.tdb.**migrateAbstractTestTransaction**.
>
> (hmm - the package name theer is a bit of a clue ...)
>
> Andy
>
>
> On 25/03/13 14:17, Claude Warren wrote:
>
>> Michael,
>>
>> I just spent some time reworking the Model tests in 2.10 so that they can
>> be run by other implementations of Model. As far as I know there has not
>> been any similar work for dataset.
>>
>> see
>> http://svn.apache.org/repos/**asf/jena/trunk/jena-core/src/**
>> test/java/com/hp/hpl/jena/rdf/**model/test/TestPackage.java<http://svn.apache.org/repos/asf/jena/trunk/jena-core/src/test/java/com/hp/hpl/jena/rdf/model/test/TestPackage.java>
>>
>> for an example of how to implement the TestingModelFactory and plug it
>> into
>> the testing framework.
>>
>> As I recall there is a directory of testing files that need to be included
>> (there is a defect for this that I have not had a chance to work on yet).
>>
>> https://github.com/Claudenw/**JenaSecurity/blob/master/**
>> JenaSecurity/src/test/java/**org/xenei/jena/security/**
>> contract/model/TestPackage.**java<https://github.com/Claudenw/JenaSecurity/blob/master/JenaSecurity/src/test/java/org/xenei/jena/security/contract/model/TestPackage.java>
>> Shows how I used the tests in a 3rd party package.
>>
>> Claude
>>
>> On Mon, Mar 25, 2013 at 12:18 PM, Mike Grove <mi...@clarkparsia.com>
>> wrote:
>>
>> I am wondering what would be the best choice to see if a custom
>>> Model/Dataset worked as expected? I have some custom tests, but I'm sure
>>> those are a bit short on coverage. So if there was some way I could
>>> re-use
>>> the same tests Jena uses, that'd be helpful.
>>>
>>> Thanks.
>>>
>>> Michael
>>>
>>>
>>
>>
>>
>
Re: compliance test suite?
Posted by Claude Warren <cl...@xenei.com>.
How about we open 2 jira tickets, one (the quick fix) to add transactions
to the current tests where appropriate, the other to do the full rewrite.
On Thu, Aug 15, 2013 at 1:20 PM, Andy Seaborne <an...@apache.org> wrote:
> 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 <cl...@xenei.com> 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 <mi...@clarkparsia.com> wrote:
>>>
>>> On Sun, Aug 4, 2013 at 4:46 AM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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/user.**php?claude@xenei.com<ht...@xenei.com>
>>>>> LinkedIn: http://www.linkedin.com/in/**claudewarren<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/user.**php?claude@xenei.com<ht...@xenei.com>
>>> LinkedIn: http://www.linkedin.com/in/**claudewarren<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/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: compliance test suite?
Posted by Andy Seaborne <an...@apache.org>.
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 <cl...@xenei.com> 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 <mi...@clarkparsia.com> wrote:
>>
>>> On Sun, Aug 4, 2013 at 4:46 AM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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/user.php?claude@xenei.com
>>>> 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/user.php?claude@xenei.com
>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>
>
Re: compliance test suite?
Posted by Mike Grove <mi...@clarkparsia.com>.
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 <cl...@xenei.com> 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 <mi...@clarkparsia.com> wrote:
>
> > On Sun, Aug 4, 2013 at 4:46 AM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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/user.php?claude@xenei.com
> > > 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/user.php?claude@xenei.com
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Re: compliance test suite?
Posted by Claude Warren <cl...@xenei.com>.
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 <mi...@clarkparsia.com> wrote:
> On Sun, Aug 4, 2013 at 4:46 AM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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/user.php?claude@xenei.com
> > 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/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: compliance test suite?
Posted by Mike Grove <mi...@clarkparsia.com>.
On Sun, Aug 4, 2013 at 4:46 AM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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/user.php?claude@xenei.com
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Re: compliance test suite?
Posted by Claude Warren <cl...@xenei.com>.
@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.
Anybody else care to weigh in?
On Sun, Aug 4, 2013 at 9:39 AM, Andy Seaborne <an...@apache.org> 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/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: compliance test suite?
Posted by Andy Seaborne <an...@apache.org>.
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
Re: compliance test suite?
Posted by Claude Warren <cl...@xenei.com>.
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.
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.
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
On Thu, Aug 1, 2013 at 5:09 PM, Mike Grove <mi...@clarkparsia.com> wrote:
> I'm just getting back to this, thanks for the pointers. Thanks to Claude's
> references, I got the Model & Graph tests patterns off his usage running
> and I fail most of them since it looks like most if not all changes to the
> Model/Graph are made sans-transaction.
>
> I took a brief look at the code, and it did not seem like there was a bit
> flipped that would enable them for tests. I can put autoCommit type
> functionality into the code if need be, but that seemed less than ideal.
>
> Thanks.
>
> Mike
>
>
> On Mon, Mar 25, 2013 at 11:00 AM, Andy Seaborne <an...@apache.org> wrote:
>
> > Michael,
> >
> > Most of the testing gets done on the graph-level object, Model and
> Dataset
> > are just wrapper, Dataset particularly is quite a thin wrapper. That,
> and
> > a lot of the coverage is by being used in other places.
> >
> > com.hp.hpl.jena.sparql.core.**AbstractTestDataset
> > com.hp.hpl.jena.sparql.core.**AbstractDatasetGraphTests
> >
> > com.hp.hpl.jena.graph.test.**AbstractTestGraph
> > com.hp.hpl.jena.sparql.graph.**AbstractTestGraph2
> >
> > com.hp.hpl.jena.tdb.**migrateAbstractTestTransaction**.
> >
> > (hmm - the package name theer is a bit of a clue ...)
> >
> > Andy
> >
> >
> > On 25/03/13 14:17, Claude Warren wrote:
> >
> >> Michael,
> >>
> >> I just spent some time reworking the Model tests in 2.10 so that they
> can
> >> be run by other implementations of Model. As far as I know there has
> not
> >> been any similar work for dataset.
> >>
> >> see
> >> http://svn.apache.org/repos/**asf/jena/trunk/jena-core/src/**
> >> test/java/com/hp/hpl/jena/rdf/**model/test/TestPackage.java<
> http://svn.apache.org/repos/asf/jena/trunk/jena-core/src/test/java/com/hp/hpl/jena/rdf/model/test/TestPackage.java
> >
> >>
> >> for an example of how to implement the TestingModelFactory and plug it
> >> into
> >> the testing framework.
> >>
> >> As I recall there is a directory of testing files that need to be
> included
> >> (there is a defect for this that I have not had a chance to work on
> yet).
> >>
> >> https://github.com/Claudenw/**JenaSecurity/blob/master/**
> >> JenaSecurity/src/test/java/**org/xenei/jena/security/**
> >> contract/model/TestPackage.**java<
> https://github.com/Claudenw/JenaSecurity/blob/master/JenaSecurity/src/test/java/org/xenei/jena/security/contract/model/TestPackage.java
> >
> >> Shows how I used the tests in a 3rd party package.
> >>
> >> Claude
> >>
> >> On Mon, Mar 25, 2013 at 12:18 PM, Mike Grove <mi...@clarkparsia.com>
> >> wrote:
> >>
> >> I am wondering what would be the best choice to see if a custom
> >>> Model/Dataset worked as expected? I have some custom tests, but I'm
> sure
> >>> those are a bit short on coverage. So if there was some way I could
> >>> re-use
> >>> the same tests Jena uses, that'd be helpful.
> >>>
> >>> Thanks.
> >>>
> >>> Michael
> >>>
> >>>
> >>
> >>
> >>
> >
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren