XPath on data prior to saving

[Chris Schmidt <cs...@prospricing.com>]

  I remember seeing an email on this list about not being able to query
for nodes prior to saving them, but cannot find it right now.  Is there
an alternative way to query for recently created nodes/properties
without explicitly saving the information into the repository?  I have
two sets of information that I want to create within the same session
'save'.  One node needs to reference the other, but doesn't have access
to the node itself for various reasons.  I'm attempting to do an XPath
query to retrieve the other node to create the reference, but cannot
since I haven't saved the previous node yet.  I don't want to save the
first node before creating the other if at all possible.  If the second
node fails for some reason, I don't want the first to be in the system.
Both nodes are working with the same session object.  Is it possible to
rollback multiple saves on a session?  That would enable me to save the
first node but undo it if something happens with the second.  

 

Thanks,

 

  Chris



The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. Thank you

Re: XPath on data prior to saving

[David Nuescheler <da...@day.com>]

Hi Ivan,


> .... but more like a temp folder
>  storing files to be burned on a CD when done with them.
I think that's a good analogy.

>    Would like to hear your opinion on that. Using workspaces as a custom
>  transient space.
This may be worth looking into.

I think this could be hard though. Let me try to explain.

The transient space allows to leave constraints unsatisfied between
saves. So if I have a nodetype that calls for a mandatory childnode
I can leave this unsatisfied while I am filling in the content into transient
space.
If I now want to persist this information into a custom workspace it
will not even .save(). So I think you may want to limit the use case to
"consistent" and "transient" information.
Is that correct?


Using clone, merge and update across different workspaces certainly
works in cases where you are looking at consistent content.
So one could make a "working copy" of a workspace
make your modifications, query and the merge() the result back.

regards,
david



regards,
david

Re: XPath on data prior to saving

[Ivan Latysh <iv...@gmail.com>]

David Nuescheler wrote:

>>  >   Thanks for the response Marcel, that's what I was afraid of.  As
>> You are out of luck here, JCR api are very inconsistent in regards to transient
>>  state, and it is more than a frustrating.
> 
> I thought that you may have an opinion on that particular topic ;)
> 
[skipped]
> I am not going to rehash the entire discussion about all the problems
Neither do I.

   Do u think that for a certain scenario that involves a transaction with a 
requirement that transient state has to be searcheable JCR transaction will not 
fit, so a custom solution has to be used.

   And I believe that workspace can accommodate such scenario quite nice. As you 
pointed correctly it is not a DB transaction, but more like a temp folder 
storing files to be burned on a CD when done with them.

   Would like to hear your opinion on that. Using workspaces as a custom 
transient space.

-- 
Ivan Latysh
IvanLatysh@gmail.com

Re: XPath on data prior to saving

[David Nuescheler <da...@day.com>]

Hi Ivan,

>  >   Thanks for the response Marcel, that's what I was afraid of.  As
> You are out of luck here, JCR api are very inconsistent in regards to transient
>  state, and it is more than a frustrating.

I thought that you may have an opinion on that particular topic ;)

While I appreciate that there are use cases where considering transient
items in a query result is convenient, from a repository implementation
perspective there are a lot of issues that (depending on the implementation)
cannot be resolved easily.

Based on the feedback we received during Public Review of JSR-283 we proposed
to loosen the contract so the repository is allowed to consider the transient
changes, which means that Jackrabbit could include transient
modifications in the index. This is not simple at all, but I am sure that
you guys will come up with a good proposal for a patch ;)

I am not going to rehash the entire discussion about all the problems
of including
transient modifications in the query result, but please keep in mind
that the transient
space is not to be compared to or used in similar ways as transactions
in a database
context.

regards,
david

Re: XPath on data prior to saving

[Ivan Latysh <iv...@gmail.com>]

Chris Schmidt wrote:

>   Thanks for the response Marcel, that's what I was afraid of.  As
You are out of luck here, JCR api are very inconsistent in regards to transient 
state, and it is more than a frustrating.

> another alternative, could I use versioning to effectively rollback the
> changes?  If that isn't an abuse of versioning, what would happen if a
> node is new?  Perhaps changing to a previous version of the parent node
> would be more correct, since that would take care of the case where the
> node is newly created, right?

You may try it, but also have a look at workspaces, you can save your changes 
into a different workspace and use it as a transient buffer. So when you want to 
commit merge nodes from transient space with your working space and delete when 
you want to rollback.

P.S. Hope that it helps.

-- 
Ivan Latysh
IvanLatysh@gmail.com

Re: XPath on data prior to saving

[Marcel Reutegger <ma...@gmx.net>]

Hi Chris,

Chris Schmidt wrote:
> As another alternative, could I use versioning to effectively rollback the 
> changes?  If that isn't an abuse of versioning, what would happen if a node
> is new?  Perhaps changing to a previous version of the parent node would be
> more correct, since that would take care of the case where the node is newly
> created, right?

versioning come at a cost and you should only use it when necessary. I don't 
think your use case justifies that. Furthermore you will have to take care of 
cleaning up the version storage, since the created versions are of no use after 
the overall operation completed.

regards
  marcel

RE: XPath on data prior to saving

[Chris Schmidt <cs...@prospricing.com>]

  Thanks for the response Marcel, that's what I was afraid of.  As
another alternative, could I use versioning to effectively rollback the
changes?  If that isn't an abuse of versioning, what would happen if a
node is new?  Perhaps changing to a previous version of the parent node
would be more correct, since that would take care of the case where the
node is newly created, right?

Thanks,

Chris Schmidt 

-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net] 
Sent: Friday, February 29, 2008 4:00 AM
To: users@jackrabbit.apache.org
Subject: Re: XPath on data prior to saving

Hi Chris,

Jackrabbit does not allow you to query transient modifications, it will
always 
run the query against saved *and* committed content.

as a sort of workaround you could:

- create the first part of your data in a temp location of your
workspace
- call save
- create the second part and run the query with a scope that includes
   the temp location.
- create the references in the second part
- move part one of your data to the correct location (this will not
   break references because they are based on uuid and not path)
- call final save

regards
  marcel

Chris Schmidt wrote:
>   I remember seeing an email on this list about not being able to
query
> for nodes prior to saving them, but cannot find it right now.  Is
there
> an alternative way to query for recently created nodes/properties
> without explicitly saving the information into the repository?  I have
> two sets of information that I want to create within the same session
> 'save'.  One node needs to reference the other, but doesn't have
access
> to the node itself for various reasons.  I'm attempting to do an XPath
> query to retrieve the other node to create the reference, but cannot
> since I haven't saved the previous node yet.  I don't want to save the
> first node before creating the other if at all possible.  If the
second
> node fails for some reason, I don't want the first to be in the
system.
> Both nodes are working with the same session object.  Is it possible
to
> rollback multiple saves on a session?  That would enable me to save
the
> first node but undo it if something happens with the second.  
> 
>  
> 
> Thanks,
> 
>  
> 
>   Chris
> 
> 
> 
> The information contained in this email may be confidential and/or
legally privileged. It has been sent for the sole use of the intended
recipient(s). If the reader of this message is not an intended
recipient, you are hereby notified that any unauthorized review, use,
disclosure, dissemination, distribution, or copying of this
communication, or any of its contents, is strictly prohibited. If you
have received this communication in error, please contact the sender by
reply email and destroy all copies of the original message. Thank you
> 
> 
> 



The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. Thank you

Re: XPath on data prior to saving

[Marcel Reutegger <ma...@gmx.net>]

Hi Chris,

Jackrabbit does not allow you to query transient modifications, it will always 
run the query against saved *and* committed content.

as a sort of workaround you could:

- create the first part of your data in a temp location of your workspace
- call save
- create the second part and run the query with a scope that includes
   the temp location.
- create the references in the second part
- move part one of your data to the correct location (this will not
   break references because they are based on uuid and not path)
- call final save

regards
  marcel

Chris Schmidt wrote:
>   I remember seeing an email on this list about not being able to query
> for nodes prior to saving them, but cannot find it right now.  Is there
> an alternative way to query for recently created nodes/properties
> without explicitly saving the information into the repository?  I have
> two sets of information that I want to create within the same session
> 'save'.  One node needs to reference the other, but doesn't have access
> to the node itself for various reasons.  I'm attempting to do an XPath
> query to retrieve the other node to create the reference, but cannot
> since I haven't saved the previous node yet.  I don't want to save the
> first node before creating the other if at all possible.  If the second
> node fails for some reason, I don't want the first to be in the system.
> Both nodes are working with the same session object.  Is it possible to
> rollback multiple saves on a session?  That would enable me to save the
> first node but undo it if something happens with the second.  
> 
>  
> 
> Thanks,
> 
>  
> 
>   Chris
> 
> 
> 
> The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. Thank you
> 
> 
>