You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Lukas Kahwe Smith <ml...@pooteeweet.org> on 2011/08/19 17:14:00 UTC
upsert, same name siblings etc
Hi,
So I am seeing behavior in production where I end up with same name siblings, the chances for that are pretty slim since its inside an import that checks if for the given path the data exists before starting the import which takes just a few ms.
What is stranger is that locally I cannot get same name siblings ever. Even if I disable the up front check all I get is an ItemExistsException. Is it because in production I am using MySQL for persistence and locally I am using the File System? Aka File System just doesnt support same name siblings?
If so it would be great if such feature different would be mentioned on:
http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ#LocalFileSystem:
At any rate I do not want same name siblings. I guess I can create a custom node type to prevent this from happening. But what I wonder is if I can then also somehow ensure that if I try to add a node to a path that already exists that it simply updates the content (with a new revision) instead, kind of a versioned upsert? Or will I always have to implement something like this locally by locking the parent to prevent concurrency?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Re: upsert, same name siblings etc
Posted by Lukas Kahwe Smith <ml...@pooteeweet.org>.
On 19.08.2011, at 17:57, Stefan Guggisberg wrote:
>> BTW: dont think this is important in this context but I am using the Davex APi via Jackalope (PHP implementation of JCR).
>
> erm, sure it is import. my comments were based on jackrabbit (core)...
> i am not familiar with your stack.
my stack is basically:
app php -> jackalope (php lib) -> davex -> jackrabbit
anyway .. i will write a test case to try and see why i cannot get any same name siblings on my local file system using setup while i do get them in the production mysql using setup.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Re: upsert, same name siblings etc
Posted by Stefan Guggisberg <st...@gmail.com>.
On Fri, Aug 19, 2011 at 5:49 PM, Lukas Kahwe Smith <ml...@pooteeweet.org> wrote:
>
> On 19.08.2011, at 17:45, Stefan Guggisberg wrote:
>
>> On Fri, Aug 19, 2011 at 5:14 PM, Lukas Kahwe Smith <ml...@pooteeweet.org> wrote:
>>> Hi,
>>>
>>> So I am seeing behavior in production where I end up with same name siblings, the chances for that are pretty slim since its inside an import that checks if for the given path the data exists before starting the import which takes just a few ms.
>>
>> there's either a bug in your client code or the node in question has
>> been created in the meantime by another session.
>>
>>>
>>> What is stranger is that locally I cannot get same name siblings ever. Even if I disable the up front check all I get is an ItemExistsException. Is it because in production I am using MySQL for persistence and locally I am using the File System? Aka File System just doesnt support same name siblings?
>>
>> no.
>>
>> you're most likely using different node types on the parent node.
>> whether a node can have SNS-child nodes is governed by the its (i.e.
>> the parent node) node type.
>
> no .. the node type is identical .. in both cases its nt:unstructured
>
> so this is really puzzeling me then .. why do i get an exception when i try to create a node with the same path on an nt:unstructure parent?
>
>>> If so it would be great if such feature different would be mentioned on:
>>> http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ#LocalFileSystem:
>>>
>>> At any rate I do not want same name siblings. I guess I can create a custom node type to prevent this from happening. But what I wonder is if I can then also somehow ensure that if I try to add a node to a path that already exists that it simply updates the content (with a new revision) instead, kind of a versioned upsert?
>>
>> that's unfortunately not supported.
>>
>>> Or will I always have to implement something like this locally by locking the parent to prevent concurrency?
>>
>> that's one possibility, yes. alternatively you could also serialize
>> the node creation code or use something like this:
>>
>> Node parent = ...;
>> Node child = null;
>> if (!parent.hasNode("child")) {
>> try {
>> child = parent.addNode("child");
>> session.save();
>> } catch (RepositoryException e) {
>> // the node might just have been created by another session,
>> // try again
>> child = parent.getNode("child");
>> }
>> } else {
>> child = parent.getNode("child");
>> }
>
>
> yeah .. kind of pessimistic vs. optimistic locking. not sure if the layer that i am using for access can be made to deal with the optimistic locking situation, as it kind of wants me to do a full rest of the "transaction" whenever i encounter an issue.
>
> BTW: dont think this is important in this context but I am using the Davex APi via Jackalope (PHP implementation of JCR).
erm, sure it is import. my comments were based on jackrabbit (core)...
i am not familiar with your stack.
cheers
stefan
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
>
>
>
Re: upsert, same name siblings etc
Posted by Lukas Kahwe Smith <ml...@pooteeweet.org>.
On 19.08.2011, at 17:45, Stefan Guggisberg wrote:
> On Fri, Aug 19, 2011 at 5:14 PM, Lukas Kahwe Smith <ml...@pooteeweet.org> wrote:
>> Hi,
>>
>> So I am seeing behavior in production where I end up with same name siblings, the chances for that are pretty slim since its inside an import that checks if for the given path the data exists before starting the import which takes just a few ms.
>
> there's either a bug in your client code or the node in question has
> been created in the meantime by another session.
>
>>
>> What is stranger is that locally I cannot get same name siblings ever. Even if I disable the up front check all I get is an ItemExistsException. Is it because in production I am using MySQL for persistence and locally I am using the File System? Aka File System just doesnt support same name siblings?
>
> no.
>
> you're most likely using different node types on the parent node.
> whether a node can have SNS-child nodes is governed by the its (i.e.
> the parent node) node type.
no .. the node type is identical .. in both cases its nt:unstructured
so this is really puzzeling me then .. why do i get an exception when i try to create a node with the same path on an nt:unstructure parent?
>> If so it would be great if such feature different would be mentioned on:
>> http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ#LocalFileSystem:
>>
>> At any rate I do not want same name siblings. I guess I can create a custom node type to prevent this from happening. But what I wonder is if I can then also somehow ensure that if I try to add a node to a path that already exists that it simply updates the content (with a new revision) instead, kind of a versioned upsert?
>
> that's unfortunately not supported.
>
>> Or will I always have to implement something like this locally by locking the parent to prevent concurrency?
>
> that's one possibility, yes. alternatively you could also serialize
> the node creation code or use something like this:
>
> Node parent = ...;
> Node child = null;
> if (!parent.hasNode("child")) {
> try {
> child = parent.addNode("child");
> session.save();
> } catch (RepositoryException e) {
> // the node might just have been created by another session,
> // try again
> child = parent.getNode("child");
> }
> } else {
> child = parent.getNode("child");
> }
yeah .. kind of pessimistic vs. optimistic locking. not sure if the layer that i am using for access can be made to deal with the optimistic locking situation, as it kind of wants me to do a full rest of the "transaction" whenever i encounter an issue.
BTW: dont think this is important in this context but I am using the Davex APi via Jackalope (PHP implementation of JCR).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Re: upsert, same name siblings etc
Posted by Stefan Guggisberg <st...@gmail.com>.
On Fri, Aug 19, 2011 at 5:14 PM, Lukas Kahwe Smith <ml...@pooteeweet.org> wrote:
> Hi,
>
> So I am seeing behavior in production where I end up with same name siblings, the chances for that are pretty slim since its inside an import that checks if for the given path the data exists before starting the import which takes just a few ms.
there's either a bug in your client code or the node in question has
been created in the meantime by another session.
>
> What is stranger is that locally I cannot get same name siblings ever. Even if I disable the up front check all I get is an ItemExistsException. Is it because in production I am using MySQL for persistence and locally I am using the File System? Aka File System just doesnt support same name siblings?
no.
you're most likely using different node types on the parent node.
whether a node can have SNS-child nodes is governed by the its (i.e.
the parent node) node type.
>
> If so it would be great if such feature different would be mentioned on:
> http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ#LocalFileSystem:
>
> At any rate I do not want same name siblings. I guess I can create a custom node type to prevent this from happening. But what I wonder is if I can then also somehow ensure that if I try to add a node to a path that already exists that it simply updates the content (with a new revision) instead, kind of a versioned upsert?
that's unfortunately not supported.
> Or will I always have to implement something like this locally by locking the parent to prevent concurrency?
that's one possibility, yes. alternatively you could also serialize
the node creation code or use something like this:
Node parent = ...;
Node child = null;
if (!parent.hasNode("child")) {
try {
child = parent.addNode("child");
session.save();
} catch (RepositoryException e) {
// the node might just have been created by another session,
// try again
child = parent.getNode("child");
}
} else {
child = parent.getNode("child");
}
cheers
stefan
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
>
>
>