You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Arto My Friend <na...@gmail.com> on 2013/12/23 11:56:49 UTC
How does Spatial Indexed Model (Lucene) different from normal Jena model?
My code was working fine, creating a resource and later read from it..
Dataset dataset = TDBFactory.createDataset(TDB_PATH);
dataset.begin(ReadWrite.WRITE);
model = dataset.getDefaultModel();
String uid = generateUUID();
Resource user = model.createResource(BASE_URI + RES_PREFIX_USER + uid)
.addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC +
uid))
.addProperty(FOAF.mbox, email)
.addProperty(PROP_UUID, uid);
dataset.commit();
model.close();
dataset.end();
String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
However, after I changed the way I retrieve dataset to be
Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
EntityDefinition entDef = new EntityDefinition("entityField", "geoField");
dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
entDef);
The program throw out ClosedException at the call of getProperty().
It seems to me that after base dataset is joined with spatial index, the
retrieved resource cannot be read outside a transaction block.
Please help. I want to know what underlying mechanisms that I should
understand to get my code right?
Art
Re: How does Spatial Indexed Model (Lucene) different from normal
Jena model?
Posted by Andy Seaborne <an...@apache.org>.
On 24/12/13 20:00, Arto My Friend wrote:
> Thanks Andy,
>
> I ran smoothly with Sun JVM "1.7.0_45"
> Jena-lib 2.11.0
> Jena-TDB 1.0.0
> Jena-spatial 1.0.1
>
> Which is supposed to be the latest release version? (not nightly build)
Yes apache-jena-libs 2.11.0 (type POM) for the core stuff and
Jena-spatial 1.0.1
>
> I am ok with transaction pattern now, so probably this is just for bug
> investigation.
>
> Art
>
>
> On Tue, Dec 24, 2013 at 6:17 AM, Andy Seaborne <an...@apache.org> wrote:
>> On 23/12/13 18:00, Arto My Friend wrote:
>>>
>>> Thanks a lot Andy, it's very helpful insight.
>>>
>>>
>>> Knowing about expected usage pattern, I decided to change my approach
>>> passing primitive Java type out of triple, rather than sending Jena's
>>> Resource around.
>>>
>>> Anyway, to my own curiosity as well, I can assure you that the first
>>> example is actually working. (A bug or feature?)
>>> Here is the gist I made for you to try out with maven dependencies
>>>
>>> https://gist.github.com/ultra-nabito/8101569
>>
>>
>> Great thanks.
>>
>> I get:
>>
>> Exception in thread "main" com.hp.hpl.jena.shared.ClosedException: already
>> closed
>>
>> at
>>
>> String s = user.getProperty(PROP_UUID).getString();
>>
>> which version are you running?
>>
>>
>>>
>>> By the way, I still not clear on what you mean by 'models are just views
>>> on
>>> the dataset at a particular transaction time'
>>> if for sometime later the data in TDB get updated, do I need to do
>>> dataset.
>>> begin(ReadWrite.WRITE);; and dataset.getDefaultModel(); again so to get
>>> Model object that reflects the changed data?
>>
>>
>> Yes. Once you start using transactions, you should always use transactions.
>> For historical reasons, TDB will work without (and it's not autocommit).
>>
>> In practical terms, and the current codebase :-), a Graph from TDB is just a
>> way of filling in the 4th slot of a quad or using the default graph tables.
>>
>> Models in Jena are built around Graphs and the only additional state is some
>> caching.
>>
>> So Models are effectively database views with a specific API.
>>
>> Andy
>>
>>
>>>
>>> Art
>>>
>>>
>>> On Mon, Dec 23, 2013 at 11:30 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>>> On 23/12/13 10:56, Arto My Friend wrote:
>>>>
>>>>> My code was working fine, creating a resource and later read from it..
>>>>>
>>>>> Dataset dataset = TDBFactory.createDataset(TDB_PATH);
>>>>>
>>>>> dataset.begin(ReadWrite.WRITE);
>>>>> model = dataset.getDefaultModel();
>>>>>
>>>>> String uid = generateUUID();
>>>>>
>>>>> Resource user = model.createResource(BASE_URI + RES_PREFIX_USER +
>>>>> uid)
>>>>> .addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC
>>>>> +
>>>>> uid))
>>>>> .addProperty(FOAF.mbox, email)
>>>>> .addProperty(PROP_UUID, uid);
>>>>>
>>>>>
>>>>> dataset.commit();
>>>>> model.close();
>>>>> dataset.end();
>>>>>
>>>>> String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
>>>>>
>>>>>
>>>>> However, after I changed the way I retrieve dataset to be
>>>>>
>>>>> Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
>>>>>
>>>>> EntityDefinition entDef = new EntityDefinition("entityField",
>>>>> "geoField");
>>>>>
>>>>> dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
>>>>> entDef);
>>>>>
>>>>>
>>>>> The program throw out ClosedException at the call of getProperty().
>>>>> It seems to me that after base dataset is joined with spatial index, the
>>>>> retrieved resource cannot be read outside a transaction block.
>>>>>
>>>>> Please help. I want to know what underlying mechanisms that I should
>>>>> understand to get my code right?
>>>>>
>>>>> I'm surprised it works the first way at all - when I tried to write a
>>>>
>>>> test for it, I get ClosedException when accessing the resource after the
>>>> model is closed.
>>>>
>>>> The text daatset example looks correct. model is closed so
>>>> user.getProperty should throw an exception. If you've done "model.close"
>>>> all access to the model should cause the exception and "user" contains a
>>>> reference to the model internally.
>>>>
>>>> If you have a complete, minimal example, could you send it and I can
>>>> debug
>>>> it.
>>>>
>>>> When used with TDB, models are just views on the dataset at a particular
>>>> transaction time. The model.close isn't necessary although you may wish
>>>> to
>>>> do it, but do it inside the transaction because you, correctly, got the
>>>> model inside the transaction. (History: when we have BDB support, closing
>>>> things properly was essential as it release BDB resources.)
>>>>
>>>> Things can't pass the transaction boundary although given the internal
>>>> details of TDB (it's effectively a MVCC system) it is possible some can
>>>> work much fop the time (later updates may break them).
>>>>
>>>> Good use is to nest inside a transaction and what is inside a transaction
>>>> is scoped to the transaction.
>>>>
>>>> Andy
>>>>
>>>>
>>>>
>>>>> Art
>>>>>
>>>>>
>>>>
>>>
>>
Re: How does Spatial Indexed Model (Lucene) different from normal
Jena model?
Posted by Arto My Friend <na...@gmail.com>.
Thanks Andy,
I ran smoothly with Sun JVM "1.7.0_45"
Jena-lib 2.11.0
Jena-TDB 1.0.0
Jena-spatial 1.0.1
Which is supposed to be the latest release version? (not nightly build)
I am ok with transaction pattern now, so probably this is just for bug
investigation.
Art
On Tue, Dec 24, 2013 at 6:17 AM, Andy Seaborne <an...@apache.org> wrote:
> On 23/12/13 18:00, Arto My Friend wrote:
>>
>> Thanks a lot Andy, it's very helpful insight.
>>
>>
>> Knowing about expected usage pattern, I decided to change my approach
>> passing primitive Java type out of triple, rather than sending Jena's
>> Resource around.
>>
>> Anyway, to my own curiosity as well, I can assure you that the first
>> example is actually working. (A bug or feature?)
>> Here is the gist I made for you to try out with maven dependencies
>>
>> https://gist.github.com/ultra-nabito/8101569
>
>
> Great thanks.
>
> I get:
>
> Exception in thread "main" com.hp.hpl.jena.shared.ClosedException: already
> closed
>
> at
>
> String s = user.getProperty(PROP_UUID).getString();
>
> which version are you running?
>
>
>>
>> By the way, I still not clear on what you mean by 'models are just views
>> on
>> the dataset at a particular transaction time'
>> if for sometime later the data in TDB get updated, do I need to do
>> dataset.
>> begin(ReadWrite.WRITE);; and dataset.getDefaultModel(); again so to get
>> Model object that reflects the changed data?
>
>
> Yes. Once you start using transactions, you should always use transactions.
> For historical reasons, TDB will work without (and it's not autocommit).
>
> In practical terms, and the current codebase :-), a Graph from TDB is just a
> way of filling in the 4th slot of a quad or using the default graph tables.
>
> Models in Jena are built around Graphs and the only additional state is some
> caching.
>
> So Models are effectively database views with a specific API.
>
> Andy
>
>
>>
>> Art
>>
>>
>> On Mon, Dec 23, 2013 at 11:30 PM, Andy Seaborne <an...@apache.org> wrote:
>>
>>> On 23/12/13 10:56, Arto My Friend wrote:
>>>
>>>> My code was working fine, creating a resource and later read from it..
>>>>
>>>> Dataset dataset = TDBFactory.createDataset(TDB_PATH);
>>>>
>>>> dataset.begin(ReadWrite.WRITE);
>>>> model = dataset.getDefaultModel();
>>>>
>>>> String uid = generateUUID();
>>>>
>>>> Resource user = model.createResource(BASE_URI + RES_PREFIX_USER +
>>>> uid)
>>>> .addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC
>>>> +
>>>> uid))
>>>> .addProperty(FOAF.mbox, email)
>>>> .addProperty(PROP_UUID, uid);
>>>>
>>>>
>>>> dataset.commit();
>>>> model.close();
>>>> dataset.end();
>>>>
>>>> String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
>>>>
>>>>
>>>> However, after I changed the way I retrieve dataset to be
>>>>
>>>> Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
>>>>
>>>> EntityDefinition entDef = new EntityDefinition("entityField",
>>>> "geoField");
>>>>
>>>> dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
>>>> entDef);
>>>>
>>>>
>>>> The program throw out ClosedException at the call of getProperty().
>>>> It seems to me that after base dataset is joined with spatial index, the
>>>> retrieved resource cannot be read outside a transaction block.
>>>>
>>>> Please help. I want to know what underlying mechanisms that I should
>>>> understand to get my code right?
>>>>
>>>> I'm surprised it works the first way at all - when I tried to write a
>>>
>>> test for it, I get ClosedException when accessing the resource after the
>>> model is closed.
>>>
>>> The text daatset example looks correct. model is closed so
>>> user.getProperty should throw an exception. If you've done "model.close"
>>> all access to the model should cause the exception and "user" contains a
>>> reference to the model internally.
>>>
>>> If you have a complete, minimal example, could you send it and I can
>>> debug
>>> it.
>>>
>>> When used with TDB, models are just views on the dataset at a particular
>>> transaction time. The model.close isn't necessary although you may wish
>>> to
>>> do it, but do it inside the transaction because you, correctly, got the
>>> model inside the transaction. (History: when we have BDB support, closing
>>> things properly was essential as it release BDB resources.)
>>>
>>> Things can't pass the transaction boundary although given the internal
>>> details of TDB (it's effectively a MVCC system) it is possible some can
>>> work much fop the time (later updates may break them).
>>>
>>> Good use is to nest inside a transaction and what is inside a transaction
>>> is scoped to the transaction.
>>>
>>> Andy
>>>
>>>
>>>
>>>> Art
>>>>
>>>>
>>>
>>
>
Re: How does Spatial Indexed Model (Lucene) different from normal
Jena model?
Posted by Andy Seaborne <an...@apache.org>.
On 23/12/13 18:00, Arto My Friend wrote:
> Thanks a lot Andy, it's very helpful insight.
>
>
> Knowing about expected usage pattern, I decided to change my approach
> passing primitive Java type out of triple, rather than sending Jena's
> Resource around.
>
> Anyway, to my own curiosity as well, I can assure you that the first
> example is actually working. (A bug or feature?)
> Here is the gist I made for you to try out with maven dependencies
>
> https://gist.github.com/ultra-nabito/8101569
Great thanks.
I get:
Exception in thread "main" com.hp.hpl.jena.shared.ClosedException:
already closed
at
String s = user.getProperty(PROP_UUID).getString();
which version are you running?
>
> By the way, I still not clear on what you mean by 'models are just views on
> the dataset at a particular transaction time'
> if for sometime later the data in TDB get updated, do I need to do dataset.
> begin(ReadWrite.WRITE);; and dataset.getDefaultModel(); again so to get
> Model object that reflects the changed data?
Yes. Once you start using transactions, you should always use
transactions. For historical reasons, TDB will work without (and it's
not autocommit).
In practical terms, and the current codebase :-), a Graph from TDB is
just a way of filling in the 4th slot of a quad or using the default
graph tables.
Models in Jena are built around Graphs and the only additional state is
some caching.
So Models are effectively database views with a specific API.
Andy
>
> Art
>
>
> On Mon, Dec 23, 2013 at 11:30 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> On 23/12/13 10:56, Arto My Friend wrote:
>>
>>> My code was working fine, creating a resource and later read from it..
>>>
>>> Dataset dataset = TDBFactory.createDataset(TDB_PATH);
>>>
>>> dataset.begin(ReadWrite.WRITE);
>>> model = dataset.getDefaultModel();
>>>
>>> String uid = generateUUID();
>>>
>>> Resource user = model.createResource(BASE_URI + RES_PREFIX_USER + uid)
>>> .addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC +
>>> uid))
>>> .addProperty(FOAF.mbox, email)
>>> .addProperty(PROP_UUID, uid);
>>>
>>>
>>> dataset.commit();
>>> model.close();
>>> dataset.end();
>>>
>>> String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
>>>
>>>
>>> However, after I changed the way I retrieve dataset to be
>>>
>>> Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
>>>
>>> EntityDefinition entDef = new EntityDefinition("entityField",
>>> "geoField");
>>>
>>> dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
>>> entDef);
>>>
>>>
>>> The program throw out ClosedException at the call of getProperty().
>>> It seems to me that after base dataset is joined with spatial index, the
>>> retrieved resource cannot be read outside a transaction block.
>>>
>>> Please help. I want to know what underlying mechanisms that I should
>>> understand to get my code right?
>>>
>>> I'm surprised it works the first way at all - when I tried to write a
>> test for it, I get ClosedException when accessing the resource after the
>> model is closed.
>>
>> The text daatset example looks correct. model is closed so
>> user.getProperty should throw an exception. If you've done "model.close"
>> all access to the model should cause the exception and "user" contains a
>> reference to the model internally.
>>
>> If you have a complete, minimal example, could you send it and I can debug
>> it.
>>
>> When used with TDB, models are just views on the dataset at a particular
>> transaction time. The model.close isn't necessary although you may wish to
>> do it, but do it inside the transaction because you, correctly, got the
>> model inside the transaction. (History: when we have BDB support, closing
>> things properly was essential as it release BDB resources.)
>>
>> Things can't pass the transaction boundary although given the internal
>> details of TDB (it's effectively a MVCC system) it is possible some can
>> work much fop the time (later updates may break them).
>>
>> Good use is to nest inside a transaction and what is inside a transaction
>> is scoped to the transaction.
>>
>> Andy
>>
>>
>>
>>> Art
>>>
>>>
>>
>
Re: How does Spatial Indexed Model (Lucene) different from normal
Jena model?
Posted by Arto My Friend <na...@gmail.com>.
Thanks a lot Andy, it's very helpful insight.
Knowing about expected usage pattern, I decided to change my approach
passing primitive Java type out of triple, rather than sending Jena's
Resource around.
Anyway, to my own curiosity as well, I can assure you that the first
example is actually working. (A bug or feature?)
Here is the gist I made for you to try out with maven dependencies
https://gist.github.com/ultra-nabito/8101569
By the way, I still not clear on what you mean by 'models are just views on
the dataset at a particular transaction time'
if for sometime later the data in TDB get updated, do I need to do dataset.
begin(ReadWrite.WRITE);; and dataset.getDefaultModel(); again so to get
Model object that reflects the changed data?
Art
On Mon, Dec 23, 2013 at 11:30 PM, Andy Seaborne <an...@apache.org> wrote:
> On 23/12/13 10:56, Arto My Friend wrote:
>
>> My code was working fine, creating a resource and later read from it..
>>
>> Dataset dataset = TDBFactory.createDataset(TDB_PATH);
>>
>> dataset.begin(ReadWrite.WRITE);
>> model = dataset.getDefaultModel();
>>
>> String uid = generateUUID();
>>
>> Resource user = model.createResource(BASE_URI + RES_PREFIX_USER + uid)
>> .addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC +
>> uid))
>> .addProperty(FOAF.mbox, email)
>> .addProperty(PROP_UUID, uid);
>>
>>
>> dataset.commit();
>> model.close();
>> dataset.end();
>>
>> String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
>>
>>
>> However, after I changed the way I retrieve dataset to be
>>
>> Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
>>
>> EntityDefinition entDef = new EntityDefinition("entityField",
>> "geoField");
>>
>> dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
>> entDef);
>>
>>
>> The program throw out ClosedException at the call of getProperty().
>> It seems to me that after base dataset is joined with spatial index, the
>> retrieved resource cannot be read outside a transaction block.
>>
>> Please help. I want to know what underlying mechanisms that I should
>> understand to get my code right?
>>
>> I'm surprised it works the first way at all - when I tried to write a
> test for it, I get ClosedException when accessing the resource after the
> model is closed.
>
> The text daatset example looks correct. model is closed so
> user.getProperty should throw an exception. If you've done "model.close"
> all access to the model should cause the exception and "user" contains a
> reference to the model internally.
>
> If you have a complete, minimal example, could you send it and I can debug
> it.
>
> When used with TDB, models are just views on the dataset at a particular
> transaction time. The model.close isn't necessary although you may wish to
> do it, but do it inside the transaction because you, correctly, got the
> model inside the transaction. (History: when we have BDB support, closing
> things properly was essential as it release BDB resources.)
>
> Things can't pass the transaction boundary although given the internal
> details of TDB (it's effectively a MVCC system) it is possible some can
> work much fop the time (later updates may break them).
>
> Good use is to nest inside a transaction and what is inside a transaction
> is scoped to the transaction.
>
> Andy
>
>
>
>> Art
>>
>>
>
Re: How does Spatial Indexed Model (Lucene) different from normal
Jena model?
Posted by Andy Seaborne <an...@apache.org>.
On 23/12/13 10:56, Arto My Friend wrote:
> My code was working fine, creating a resource and later read from it..
>
> Dataset dataset = TDBFactory.createDataset(TDB_PATH);
>
> dataset.begin(ReadWrite.WRITE);
> model = dataset.getDefaultModel();
>
> String uid = generateUUID();
>
> Resource user = model.createResource(BASE_URI + RES_PREFIX_USER + uid)
> .addProperty(PROP_HAS_CHECKIN, model.createSeq(BASE_URI + RES_PREFIX_REC +
> uid))
> .addProperty(FOAF.mbox, email)
> .addProperty(PROP_UUID, uid);
>
>
> dataset.commit();
> model.close();
> dataset.end();
>
> String uid = user.getProperty(MobiSosCore.PROP_UUID).getString();
>
>
> However, after I changed the way I retrieve dataset to be
>
> Dataset baseDataset = TDBFactory.createDataset(TDB_PATH);
>
> EntityDefinition entDef = new EntityDefinition("entityField", "geoField");
>
> dataset = SpatialDatasetFactory.createLucene(baseDataset, INDEX_DIR,
> entDef);
>
>
> The program throw out ClosedException at the call of getProperty().
> It seems to me that after base dataset is joined with spatial index, the
> retrieved resource cannot be read outside a transaction block.
>
> Please help. I want to know what underlying mechanisms that I should
> understand to get my code right?
>
I'm surprised it works the first way at all - when I tried to write a
test for it, I get ClosedException when accessing the resource after the
model is closed.
The text daatset example looks correct. model is closed so
user.getProperty should throw an exception. If you've done
"model.close" all access to the model should cause the exception and
"user" contains a reference to the model internally.
If you have a complete, minimal example, could you send it and I can
debug it.
When used with TDB, models are just views on the dataset at a particular
transaction time. The model.close isn't necessary although you may wish
to do it, but do it inside the transaction because you, correctly, got
the model inside the transaction. (History: when we have BDB support,
closing things properly was essential as it release BDB resources.)
Things can't pass the transaction boundary although given the internal
details of TDB (it's effectively a MVCC system) it is possible some can
work much fop the time (later updates may break them).
Good use is to nest inside a transaction and what is inside a
transaction is scoped to the transaction.
Andy
>
> Art
>