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 >
