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 >
