xmldb document-id strategies

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

xmldb document-id strategies

Oliver Charlet
Hi there,

I am trying to find a general way to use the xmldb to store xml
entities. My first approach is the same as using a SQL database.
I want to insert an XML document into the xmldb. All my new XML entities
have an (empty) id attribute as their primary key.
Since I don't want to manage those ids on my own, I would like to use
the internal id, that is generated by eXist.
I just dont know, how to create a smart pipeline to both insert the
document into the xmldb and update the id attribute
to the internal document-id. I started by inserting the document and
afterwards updating its attribute. But this is very
nasty, because it is not save (no transactions) and it depends upon some
way to retrieve the new document again, to
update it.
What I am looking for is a way to insert the XML and either
1) return the new document-id as some kind of a result of the insert
(does ops's xdb:insert command support this?)
or
2) read the next document-id before I actually insert the document, so I
can update the id attribute before.
Since for me this looks like a standard pattern, somebody probably
already developed a strategy for that.

Of course there might be other ways. Maybe not using a distinct ID at
all? But how to manage changes the clever way?

Can anybody help and give me some hints here, please?

Thanks in advance
:olli



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: xmldb document-id strategies

Erik Bruchez
Administrator
Hi Olli,

I don't know if eXist has the concept of a unique sequence which you
can retrieve with XQuery. If so, that would be an easy
solution.

The BizDoc example generates a pseudo-UUID, sets it into the new
document, and then inserts the document into the collection.

You should probably try to ask this question in the eXist
mailing-list, but be sure to report back the findings!

-Erik

Oliver Charlet wrote:
 > Hi there,
 >
 > I am trying to find a general way to use the xmldb to store xml
 > entities. My first approach is the same as using a SQL database.
 > I want to insert an XML document into the xmldb. All my new XML entities
 > have an (empty) id attribute as their primary key.
 > Since I don't want to manage those ids on my own, I would like to use
 > the internal id, that is generated by eXist.
 > I just dont know, how to create a smart pipeline to both insert the
 > document into the xmldb and update the id attribute
 > to the internal document-id. I started by inserting the document and
 > afterwards updating its attribute. But this is very
 > nasty, because it is not save (no transactions) and it depends upon some
 > way to retrieve the new document again, to
 > update it.
 > What I am looking for is a way to insert the XML and either
 > 1) return the new document-id as some kind of a result of the insert
 > (does ops's xdb:insert command support this?)
 > or
 > 2) read the next document-id before I actually insert the document, so I
 > can update the id attribute before.
 > Since for me this looks like a standard pattern, somebody probably
 > already developed a strategy for that.
 >
 > Of course there might be other ways. Maybe not using a distinct ID at
 > all? But how to manage changes the clever way?
 >
 > Can anybody help and give me some hints here, please?
 >
 > Thanks in advance
 > :olli




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: xmldb document-id strategies

kkoger
In reply to this post by Oliver Charlet
Why was the choice made to use a random uuid in "new-document-action.xpl"?  Was this simply for illustration purposes?  It would seem in most applications the document would be filed based on a user provided ID, or a count of documents would be performed and then incremented for a new ID.  Then the summary could be sorted by ID, and names per previous comment.   I have played a little with replacing the generator by the incremental approach; have not been successful  yet but had to put it aside for several weeks.

Also BIZDOC related, are document-optional-info.rng, document-info.rng, and document-id.rng actually ever used by either bizdoc or bizdoc2?  I have tried to find where, but have not had any luck.  It appears to me only the .xsd files are used?

BTW, the link "My Blog" on http://www.orbeon.com/ops/goto-example/blog  craps out when I tried it.

>>> [hidden email] 08/03/05 09:11PM >>>
Hi Olli,

I don't know if eXist has the concept of a unique sequence which you
can retrieve with XQuery. If so, that would be an easy
solution.

The BizDoc example generates a pseudo-UUID, sets it into the new
document, and then inserts the document into the collection.

You should probably try to ask this question in the eXist
mailing-list, but be sure to report back the findings!

-Erik

Oliver Charlet wrote:

> Hi there,
>
> I am trying to find a general way to use the xmldb to store xml
> entities. My first approach is the same as using a SQL database.
> I want to insert an XML document into the xmldb. All my new XML entities
> have an (empty) id attribute as their primary key.
> Since I don't want to manage those ids on my own, I would like to use
> the internal id, that is generated by eXist.
> I just dont know, how to create a smart pipeline to both insert the
> document into the xmldb and update the id attribute
> to the internal document-id. I started by inserting the document and
> afterwards updating its attribute. But this is very
> nasty, because it is not save (no transactions) and it depends upon some
> way to retrieve the new document again, to
> update it.
> What I am looking for is a way to insert the XML and either
> 1) return the new document-id as some kind of a result of the insert
> (does ops's xdb:insert command support this?)
> or
> 2) read the next document-id before I actually insert the document, so I
> can update the id attribute before.
> Since for me this looks like a standard pattern, somebody probably
> already developed a strategy for that.
>
> Of course there might be other ways. Maybe not using a distinct ID at
> all? But how to manage changes the clever way?
>
> Can anybody help and give me some hints here, please?
>
> Thanks in advance
> :olli


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

TEXT.htm (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: xmldb document-id strategies

Erik Bruchez
Administrator
Kurt Koger wrote:

 > Why was the choice made to use a random uuid in
 > "new-document-action.xpl"?  Was this simply for illustration
 > purposes?

Sure, it's an example after all. It is also because this was a really
simple method.

 > It would seem in most applications the document would be filed based
 > on a user provided ID

Usually not for the unique id which identifies the document in the
database! That kind of id is usually provided with a database sequence
or similar concept.

 > or a count of documents would be performed and then incremented for
 > a new ID.

Count of documents is not a good idea, as if you delete documents you
would obtain ids that have already been used.

 > Then the summary could be sorted by ID, and names per previous
 > comment.

There is usually no point in sorting documents or database rows by id,
unless the id has a meaning. A creation or update date would make more
sense for sorting.

 > I have played a little with replacing the generator by the
 > incremental approach; have not been successful yet but had to put it
 > aside for several weeks.
 >
 > Also BIZDOC related, are document-optional-info.rng,
 > document-info.rng, and document-id.rng actually ever used by either
 > bizdoc or bizdoc2?  I have tried to find where, but have not had any
 > luck.  It appears to me only the .xsd files are used?

A quick search finds this:

document-info.rng

   bizdoc/data-access/delegate/create-document.xpl
   bizdoc/data-access/delegate/update-document.xpl
   bizdoc/data-access/exist/create-document.xpl
   bizdoc/data-access/exist/update-document.xpl
   bizdoc/data-access/sql/create-document.xpl
   bizdoc/data-access/sql/update-document.xpl

document-info-optional.rng

   bizdoc/data-access/delegate/read-document.xpl
   bizdoc/data-access/exist/read-document.xpl
   bizdoc/data-access/sql/read-document.xpl

document-id.rng

   bizdoc/data-access/delegate/delete-document.xpl
   bizdoc/data-access/delegate/read-document.xpl
   bizdoc/data-access/exist/delete-document.xpl
   bizdoc/data-access/exist/read-document.xpl
   bizdoc/data-access/sql/delete-document.xpl
   bizdoc/data-access/sql/read-document.xpl
   bizdoc/detail/xml-detail-xforms-model.xml

 > BTW, the link "My Blog" on
 > http://www.orbeon.com/ops/goto-example/blog craps out when I tried
 > it.

Yes, this example is not finished yet.

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

RE: xmldb document-id strategies

Richard Braman
In reply to this post by kkoger

Using uuids is becoming more common in relational database applications
as a means of identifying a record.  UUIDs are unique over space and
time and can become quite useful when doing systems integration work.

Some developers prefer to use numeric ids (1,2,3,4,etc) and auto
increment them.  The auto increment feature is build into most
relational db products.  In SQL server they call it an identity field.
So unlike the example, you would pass an output parameter to your stored
procedure and SELECT @result = @@IDENTITY when you insert a new record.
The sp would return the new id that was created and your app would have
access to the value.  

Erik, is it possible to use output parametters with the orbeon sql
processor?

Those schema files files that you mentioned are are relax ng schema used
by bizdoc to validate the output of results of the data access
pipelines.  Look for schema=" in those files and you will see how they
are used.



-----Original Message-----
From: Kurt Koger [mailto:[hidden email]]
Sent: Thursday, August 04, 2005 9:46 AM
To: [hidden email]
Subject: Re: [ops-users] xmldb document-id strategies

Why was the choice made to use a random uuid in
"new-document-action.xpl"?  Was this simply for illustration purposes?
It would seem in most applications the document would be filed based on
a user provided ID, or a count of documents would be performed and then
incremented for a new ID.  Then the summary could be sorted by ID, and
names per previous comment.   I have played a little with replacing the
generator by the incremental approach; have not been successful  yet but
had to put it aside for several weeks.

Also BIZDOC related, are document-optional-info.rng, document-info.rng,
and document-id.rng actually ever used by either bizdoc or bizdoc2?  I
have tried to find where, but have not had any luck.  It appears to me
only the .xsd files are used?

BTW, the link "My Blog" on http://www.orbeon.com/ops/goto-example/blog
craps out when I tried it.

>>> [hidden email] 08/03/05 09:11PM >>>
Hi Olli,

I don't know if eXist has the concept of a unique sequence which you
can retrieve with XQuery. If so, that would be an easy
solution.

The BizDoc example generates a pseudo-UUID, sets it into the new
document, and then inserts the document into the collection.

You should probably try to ask this question in the eXist
mailing-list, but be sure to report back the findings!

-Erik

Oliver Charlet wrote:
> Hi there,
>
> I am trying to find a general way to use the xmldb to store xml
> entities. My first approach is the same as using a SQL database.
> I want to insert an XML document into the xmldb. All my new XML
entities
> have an (empty) id attribute as their primary key.
> Since I don't want to manage those ids on my own, I would like to use
> the internal id, that is generated by eXist.
> I just dont know, how to create a smart pipeline to both insert the
> document into the xmldb and update the id attribute
> to the internal document-id. I started by inserting the document and
> afterwards updating its attribute. But this is very
> nasty, because it is not save (no transactions) and it depends upon
some
> way to retrieve the new document again, to
> update it.
> What I am looking for is a way to insert the XML and either
> 1) return the new document-id as some kind of a result of the insert
> (does ops's xdb:insert command support this?)
> or
> 2) read the next document-id before I actually insert the document, so
I

> can update the id attribute before.
> Since for me this looks like a standard pattern, somebody probably
> already developed a strategy for that.
>
> Of course there might be other ways. Maybe not using a distinct ID at
> all? But how to manage changes the clever way?
>
> Can anybody help and give me some hints here, please?
>
> Thanks in advance
> :olli



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: xmldb document-id strategies

Erik Bruchez
Administrator
Richard Braman wrote:

> Erik, is it possible to use output parametters with the orbeon sql
> processor?

Not at this point. We are currently working on adding support for
calling stored procedures though. At any rate, the SQL processor will be
in much better shape real soon, and should be much easier to enhance!

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Procedure Calls in OPS 3.0 Beta?

Sebastian Kraus/INPLUS/DE
In reply to this post by Richard Braman

Hi,

Just a short question.
Calling stored procedures is not implemented yet? The ops-documentation says "it does" the ops validator disagrees.
Who knows more?

Greets

Sebastian

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Procedure Calls in OPS 3.0 Beta?

Erik Bruchez
Administrator
It depends what version of OPS you are using: if stock 2.8, the answer
is no. If one of the OPS 3.0 betas, then the answer is yes, and you
should be able to follow the online documentation:

   http://www.orbeon.com/ops/doc/processors-sql

-Erik

Sebastian Kraus/INPLUS/DE wrote:

>
> Hi,
>
> Just a short question.
> Calling stored procedures is not implemented yet? The ops-documentation
> says "it does" the ops validator disagrees.
> Who knows more?
>
> Greets
>
> Sebastian


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws