You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Claude Warren (JIRA)" <ji...@apache.org> on 2013/09/23 19:15:03 UTC
[jira] [Created] (JENA-543) Seq created from resource in another
model results in Seq from the wrong model.
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
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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (JENA-543) Seq created from resource in another
model results in Seq from the wrong model.
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> 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 <cl...@xenei.com> 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 <an...@apache.org> 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
Re: [jira] [Created] (JENA-543) Seq created from resource in another
model results in Seq from the wrong model.
Posted by Andy Seaborne <an...@apache.org>.
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 <cl...@xenei.com> 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 <an...@apache.org> 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>
>>>> 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
>>
>
>
>
Re: [jira] [Created] (JENA-543) Seq created from resource in another
model results in Seq from the wrong model.
Posted by Claude Warren <cl...@xenei.com>.
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.
- 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 <cl...@xenei.com> 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 <an...@apache.org> 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>
>>> 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
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [jira] [Created] (JENA-543) Seq created from resource in another
model results in Seq from the wrong model.
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> 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>
>> 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
Re: [jira] [Created] (JENA-543) Seq created from resource in another
model results in Seq from the wrong model.
Posted by Andy Seaborne <an...@apache.org>.
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
> 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