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 <[email protected]> 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 <[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/user.**[email protected]<https://www.identify.nu/[email protected]> >>>>> 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.**[email protected]<https://www.identify.nu/[email protected]> >>> 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/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
