BaseX as persistence layer

> QUESTION: If I rerun the above, will it overwrite the DB if it already > exists, or will it just open the existing DB? Can't find anything in the > API about that.

> for $x in /forum/users/User > where $x/username="Chas" > return replace node $x with " + chas

chas at munat.com schrieb: > I'm trying to use BaseX as a persistence layer in a project (together with > XStream). I have a few questions and I'm not having any luck with the > documentation. > > I've gotten pretty far. I have a User object (simplified for this example) > with an id (UUID), a username (String), and a password (String). XStream > turns this into: > > <User> > <id>98bdb472-97ad-4de1-b1c6-a482d7f06d94</id> > <username>Chas</username> > <password>secret</password> > </User> > > I've created a DB called "db" (clever, huh?): > > new CreateDB("cop", "<blog><users/></blog>").execute(context) > > QUESTION: If I rerun the above, will it overwrite the DB if it already > exists, or will it just open the existing DB? Can't find anything in the > API about that. > > Then I save my User like this: > > new XQuery("insert node" + chas + " into /blog/users").execute(context) > > where chas is the above XML. > > This works great! When I need to reinflate the object, I just do: > > chas = new XQuery(""" > for $x in /forum/users/User > where $x/username="Chas" > return $x > """).execute(context) > > Then I use XStream to reinflate the object. > > Any suggestions for improvement? > > So now the problem. I need to update this object in the database. The > simplest way is just to update the whole object. So I change my username > and use XStream to create the new XML: > > <User> > <id>98bdb472-97ad-4de1-b1c6-a482d7f06d94</id> > <username>Charles</username> > <password>secret</password> > </User> > > I read that one must use put() to export the changes, but maybe I'm > misunderstanding this. I'm have this: > > for $x in /forum/users/User > where $x/username="Chas" > return replace node $x with " + chas > > This and seems to work, but then when I try to delete the node thus: > > for $x in /forum/users/User > where $x/password="secret" > return delete nodes $x > > It does not work. What am I missing? > > Thanks for any help. If this thing works, I'm happy to open it up so > others can work on it, too. > > Chas. > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

Am 16.08.2010 11:41, schrieb chas at munat.com: > chas = new XQuery(""" > for $x in /forum/users/User > where $x/username="Chas" > return $x > """).execute(context)

Am 16.08.2010 12:00, schrieb Andreas Weiler: > for $x in /forum/users/User > where $x/username="Chas" > return replace value of node $x/username with " + chas

> Then this one should work: > > for $x in /forum/users/User > where $x/password="secret" > return delete nodes $x

On Mon, Aug 16, 2010 at 7:06 PM, Dave Glick <dglick at dracorp.com> wrote: > Hello, > > I think there might be a bug in Data.pre()... > > When you use Data.id() to get the id for a given pre, it's easy enough to check Data.meta.size to make sure you're not asking for the id of a pre value that's beyond the end of the table since pre values are contiguous and are maintained when the database is updated. > > However, I've noticed some crashes when asking for the pre value of a given id using Data.pre(). Specifically, if I create a large database and then remove all but a few nodes I have a very large Data.meta.lastid value but a very small Data.meta.size. If I then ask for the pre value for a very large id using Data.pre() that may or may not still be in the database, I often end up with an exception message such as "Invalid Data Access [pre:259, indexSize:3, access:3 > 2]". The expected result would simply be -1. I think the problem is that even though the id I'm asking for is still smaller than my Data.meta.lastid value, it's large enough that after the Data.table has been resized after removing most of the nodes, the call to Data.id() within Data.pre() is probing the table beyond its boundaries as it scans. > > Did that make sense? > > Dave

-----Original Message----- From: Christian Grün [mailto:christian.gruen at gmail.com] Sent: Monday, August 16, 2010 7:36 PM To: Dave Glick Cc: BaseX-Talk at mailman.uni-konstanz.de Subject: Re: [basex-talk] Possible bug in Data.pre()? Dave, thanks for the hint. Yes, that absolutely made sense; I guess the following change (which will be uploaded with the next commit) should suffice to fix the problem: Data, line 275: for(int p = 0, ps = Math.min(meta.size, id); p < ps; ++p) if(id == id(p)) return p; Currently, due to its inefficiency, the method in question isn't used anywhere in the code. We're working on an ID-Pre mapping, which will allow us to keep on using existing index structures after update operations. This is work in progress, though; just stay tuned! Christian On Mon, Aug 16, 2010 at 7:06 PM, Dave Glick <dglick at dracorp.com> wrote: > Hello, > > I think there might be a bug in Data.pre()... > > When you use Data.id() to get the id for a given pre, it's easy enough to check Data.meta.size to make sure you're not asking for the id of a pre value that's beyond the end of the table since pre values are contiguous and are maintained when the database is updated. > > However, I've noticed some crashes when asking for the pre value of a given id using Data.pre(). Specifically, if I create a large database and then remove all but a few nodes I have a very large Data.meta.lastid value but a very small Data.meta.size. If I then ask for the pre value for a very large id using Data.pre() that may or may not still be in the database, I often end up with an exception message such as "Invalid Data Access [pre:259, indexSize:3, access:3 > 2]". The expected result would simply be -1. I think the problem is that even though the id I'm asking for is still smaller than my Data.meta.lastid value, it's large enough that after the Data.table has been resized after removing most of the nodes, the call to Data.id() within Data.pre() is probing the table beyond its boundaries as it scans. > > Did that make sense? > > Dave

Am 18.08.2010 14:48, schrieb Dave Glick: > By the way, I did notice the IDPREMAPON flag and that it's currently > set to false. Is that ready for use yet, or is it mostly for > internal testing right now?

-----Original Message----- From: Dave Glick Sent: Tuesday, August 17, 2010 8:18 AM To: 'Christian Grün' Cc: 'BaseX-Talk at mailman.uni-konstanz.de' Subject: RE: [basex-talk] Possible bug in Data.pre()? Excellent, thanks. I know a lot of people are using BaseX through the server and other APIs, but we use it directly and are thankful for the continued development on that front. We also make heavy use of the pre-to-id mapping and are especially grateful for any performance improvements you plan on making there. -----Original Message----- From: Christian Grün [mailto:christian.gruen at gmail.com] Sent: Monday, August 16, 2010 7:36 PM To: Dave Glick Cc: BaseX-Talk at mailman.uni-konstanz.de Subject: Re: [basex-talk] Possible bug in Data.pre()? Dave, thanks for the hint. Yes, that absolutely made sense; I guess the following change (which will be uploaded with the next commit) should suffice to fix the problem: Data, line 275: for(int p = 0, ps = Math.min(meta.size, id); p < ps; ++p) if(id == id(p)) return p; Currently, due to its inefficiency, the method in question isn't used anywhere in the code. We're working on an ID-Pre mapping, which will allow us to keep on using existing index structures after update operations. This is work in progress, though; just stay tuned! Christian On Mon, Aug 16, 2010 at 7:06 PM, Dave Glick <dglick at dracorp.com> wrote: > Hello, > > I think there might be a bug in Data.pre()... > > When you use Data.id() to get the id for a given pre, it's easy enough to check Data.meta.size to make sure you're not asking for the id of a pre value that's beyond the end of the table since pre values are contiguous and are maintained when the database is updated. > > However, I've noticed some crashes when asking for the pre value of a given id using Data.pre(). Specifically, if I create a large database and then remove all but a few nodes I have a very large Data.meta.lastid value but a very small Data.meta.size. If I then ask for the pre value for a very large id using Data.pre() that may or may not still be in the database, I often end up with an exception message such as "Invalid Data Access [pre:259, indexSize:3, access:3 > 2]". The expected result would simply be -1. I think the problem is that even though the id I'm asking for is still smaller than my Data.meta.lastid value, it's large enough that after the Data.table has been resized after removing most of the nodes, the call to Data.id() within Data.pre() is probing the table beyond its boundaries as it scans. > > Did that make sense? > > Dave

-----Original Message----- From: Leonard Wörteler [mailto:leonard.woerteler at uni-konstanz.de] Sent: Wednesday, August 18, 2010 9:01 AM To: basex-talk at mailman.uni-konstanz.de Cc: Dave Glick Subject: Re: [basex-talk] Possible bug in Data.pre()? Hi Dave, Am 18.08.2010 14:48, schrieb Dave Glick: > By the way, I did notice the IDPREMAPON flag and that it's currently > set to false. Is that ready for use yet, or is it mostly for > internal testing right now? these data structures are still in an early state of development and aren't safe to use yet. Sorry for that... Cheers, Leo