The symmetry I am proposing to preserve is when model.f() returns an object in the model layer the following is true: model.f().getModel() == model
model.getSeq/Alt/Bag( resource ) does not do this. I would also expect that if resource.f() returns an object in the model layer the following would be true resource.f().getModel() == resource.getModel() I would like to leave this trio of bugs open until I get all the contract tests written, then we can look at what the side effects of changing it is on the other parts of the system. I created the bugs so they would be tracked. The test code currently writes a log warning error as well so it will be easy to find the asserts that need to be modified/enabled as we move forward. On Wed, Sep 25, 2013 at 2:02 PM, Andy Seaborne <[email protected]> wrote: > On 25/09/13 12:23, Claude Warren wrote: > >> Dang it!! I hate when I hit send in error. Let me state the top part of >> that message again. >> >> There are several disconnects here that I think need to be straightened >> out >> all at once. >> >> >> - model.getSeq/Alt/Bag( resource ) - if the resource doesn't exist the >> >> result is in the model of the resource. >> - model.getSeq/Alt/Bag( resource ) - if the resource exists in the >> model >> >> the result is in the model of the method. >> > > ?? > > The code is: > > return r.as( Seq.class ) ; > > so there is symmetry here. > > Andy > > > - model.getSeq/Atl/Bag( text ) - always returns a result in the model >> of >> the method. >> - The documentation states that changes to the result may change the >> >> model implying that the result is in the model of the method. >> - model.getResource( text ) - always returns a resource in the model >> of >> the method. >> - model.getResource( text ) - states that the method behaves >> identically >> to model.createResource( text ) >> - model.createSeq/Alt/Bag( resource ) - always returns a result in the >> model of the method. >> - model.createSeq/Alt/Bag( text ) - always returns a result in the >> model >> >> of the method. >> >> >> >> >> >> >> >> On Wed, Sep 25, 2013 at 12:15 PM, Claude Warren <[email protected]> wrote: >> >> There are several disconnects here that I think need to be straightened >>> out all at once. >>> >>> >>> - >>> >>> >>> The model.getSeq/Alt/Bag( resource ) assumes that the resource exists but >>> if it doesn't it creates it in the model. >>> The model.getSeq/Alt/Bag( resource ) assumes that the resource exists but >>> if it doesn't it creates it in the model. >>> >>> to exists but if it doesn't it does not create it as expected (in the >>> model). I think should either fail (big change not recommended by me) or >>> correctly create the object. Currently it creates the object in the >>> model >>> of the resource not the model of the getSeq/Alt/Bag call. I also note >>> that >>> the documentation states that "Subsequent operations on the returned Alt >>> may modify this model." This would lead one to believe that the model >>> of >>> the resulting Seq/Alt/Bag is the model on which the getX() was called. >>> >>> The getSeq/Alt/Bag when called with a string correctly creates the object >>> in the model. >>> >>> getSeq/Alt/Bag differs from getResource() where the documentation >>> states: >>> >>> Return a Resource instance with the given URI in this model. *This method >>> behaves identically to createResource(String)* and exists as legacy: >>> >>> createResource is now capable of, and allowed to, reuse existing objects. >>> >>> I believe the getSeq/Alt/Bag( resource ) should have similar >>> documentation. I suspect that this is an artifact of the change alluded >>> to >>> in createResource() documentation. >>> >>> >>> My suggestion is: >>> >>> 1. to change the model.getSeq/Alt/Bag( resource ) to operate exactly >>> >>> like the model.createSeq/Alt/Bag( resource ). >>> 2. to alter the documentation to align it with the comments for >>> model.getResource() >>> >>> This >>> >>> 1. pulls the string version and resource versions of the >>> >>> getSeq/Alt/Bag in alignment with each other. >>> 2. brings the overall operation of similarly named methods at the >>> >>> model level in alignment with each other. >>> 3. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Sep 25, 2013 at 11:21 AM, Andy Seaborne <[email protected]> wrote: >>> >>> On 23/09/13 18:15, Claude Warren (JIRA) wrote: >>>> >>>> Claude Warren created JENA-543: >>>>> ------------------------------****---- >>>>> >>>>> >>>>> Summary: Seq created from resource in another model >>>>> results in Seq from the wrong model. >>>>> Key: JENA-543 >>>>> URL: https://issues.apache.org/**** >>>>> jira/browse/JENA-543<https://issues.apache.org/**jira/browse/JENA-543> >>>>> <https://**issues.apache.org/jira/browse/**JENA-543<https://issues.apache.org/jira/browse/JENA-543> >>>>> > >>>>> >>>>> Project: Apache Jena >>>>> Issue Type: Bug >>>>> Components: Jena >>>>> Affects Versions: Jena 2.11.0 >>>>> Reporter: Claude Warren >>>>> >>>>> >>>>> Create model 1. >>>>> Create a resource in model 1 >>>>> >>>>> Create model 2 >>>>> call Seq s = model2.getSeq( resource ) >>>>> >>>>> s.getModel() == model1 is true >>>>> s.getModel() == model2 is false >>>>> >>>>> s.getModel() should return model2 >>>>> >>>>> >>>> A general point here - this is a proposed chnage to the functionality of >>>> the RDF API. I tend towards expecting the model to be model m2 but at >>>> the >>>> same time I see that it has been the other way for quite sometime. >>>> >>>> Should it be changed or do we accept that it is what it is? >>>> >>>> Is is really a matter of javadoc? >>>> >>>> There is a hint in: >>>> >>>> """ >>>> The Seq is assumed to already exist in the model. If it does not, >>>> createAlt should be used instead. >>>> """ >>>> >>>> Andy >>>> >>>> >>>> >>> >>> -- >>> I like: Like Like - The likeliest place on the web< >>> http://like-like.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> LinkedIn: http://www.linkedin.com/in/claudewarren
