$xwiki.copyDocument, objects, and cache
When copying a document using $xwiki.copyDocument(), I find that all the attached objects are copied along with the document, and I am able to view them appropriately. However, they are not available to other users, and when I call $xwiki.flushCache(), only the document content remains; the objects are no longer attached. A further detail, whether relevant or not, is that the document being copied is a user profile document (defined as a document named XWiki.<username>, where <username> is the login name of the user, and containing an XWiki.XWikiUsers object). Yet another detail, puzzling though it may be, is that of the objects in the original, one of them is the one defined in the xwiki-db-0.9.2.sql database download as an object of XWiki class XWiki.XWikiRights with ID 165499024, with a field named "levelsye". It's one of two XWiki.XWikiRights objects attached to a user profile document by createUser; the other one explicitly gives edit permission to the user himself. No other XWiki.XWikiRights objects contain this field, nor does the current definition of the XWiki.XWikiRights class contain it; instead they contain a field called "levels". So, the questions are, in order of (logarithmically) decreasing importance: 1. How can I make this work? 2. Does a user profile document have some special status that makes it inappropriate to make a copy? 3. Is the "levelsye" field in an object simply a bug, or is there some arcane reason for its existence? Brian M. Thomas - Senior Technical Architect AT&T Services, Inc. One SBC Center, Room 24D3 St. Louis, MO 63101 314 235 3141
Hi, THOMAS, BRIAN M (SBCSI) a écrit :
When copying a document using $xwiki.copyDocument(), I find that all the attached objects are copied along with the document, and I am able to view them appropriately. However, they are not available to other users, and when I call $xwiki.flushCache(), only the document content remains; the objects are no longer attached.
A further detail, whether relevant or not, is that the document being copied is a user profile document (defined as a document named XWiki.<username>, where <username> is the login name of the user, and containing an XWiki.XWikiUsers object).
Yet another detail, puzzling though it may be, is that of the objects in the original, one of them is the one defined in the xwiki-db-0.9.2.sql database download as an object of XWiki class XWiki.XWikiRights with ID 165499024, with a field named "levelsye". It's one of two XWiki.XWikiRights objects attached to a user profile document by createUser; the other one explicitly gives edit permission to the user himself. No other XWiki.XWikiRights objects contain this field, nor does the current definition of the XWiki.XWikiRights class contain it; instead they contain a field called "levels".
So, the questions are, in order of (logarithmically) decreasing importance:
1. How can I make this work?
I'll revert the question. Which version of XWiki are you using and where are you running the copyDocument (inside a wiki page or in an external application ?) I'm a little surprised that you are having problems. I suspect creating the new document worked but it was not saved correctly to the database nor the document was shared with other users. Are you getting any error message ?
2. Does a user profile document have some special status that makes it inappropriate to make a copy?
No
3. Is the "levelsye" field in an object simply a bug, or is there some arcane reason for its existence?
It's a bug. It might have an effect on copying this exact object.
Brian M. Thomas - Senior Technical Architect AT&T Services, Inc. One SBC Center, Room 24D3 St. Louis, MO 63101 314 235 3141
------------------------------------------------------------------------
-- You receive this message as a subscriber of the xwiki-users@objectweb.org mailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
Thanks again, Ludovic, for a quick reply. I apologize for neglecting to give you the version; I'm using 0.9.840, and calling copyDocument from a Velocity script on a wiki page. And no, I'm not getting any error messages, either on the page or in the logs, with one exception: my attempts to delete the incorrectly-copied document evoked an error message, which I didn't interpret as having to do with the objects but complained of an inconsistency in item counts (e.g. expected 1, found 0) or something similar; sorry I don't have the message now. After flushing, however, the deletion succeeded. Your suspicions sound consistent with what I've seen here. There's an update to this: I edited the original document's page permissions to add "admin, programming" to the "levels" field of the corrupted rights object, which was for XWiki.XWikiAdminGroup, and the objects survived the flush. Apparently the bogus fieldname (or, more likely, the lack of the correct one) is in some way the culprit - such as causing the transaction to abort when an object with an incorrect schema was saved. Why the document and its content (an #includeForm directive) survived the aborted transaction is a mystery in that case. So, conjecturally, (apart from the incorrect DB data) the bug, if any, is that a) no error message ensued from an aborted transaction (I'm pretty sure, though not absolutely, that the logs were silent) and b) the cache was not cleared. I am adding an $xwiki.flushCache() call to the end of my copy script, at any rate, to be sure that I'm not fooled again by objects that aren't really there. At a minimum, the database dump needs to be fixed ASAP... brain[sic]
-----Original Message----- From: Ludovic Dubost [mailto:ludovic@xwiki.com] Sent: Tuesday, May 30, 2006 5:25 PM To: xwiki-users@objectweb.org Subject: Re: [xwiki-users] $xwiki.copyDocument, objects, and cache
Hi,
THOMAS, BRIAN M (SBCSI) a écrit :
When copying a document using $xwiki.copyDocument(), I find that all the attached objects are copied along with the document, and I am able to view them appropriately. However, they are not available to other users, and when I call $xwiki.flushCache(), only the document content remains; the objects are no longer attached.
A further detail, whether relevant or not, is that the document being copied is a user profile document (defined as a document named XWiki.<username>, where <username> is the login name of the user, and containing an XWiki.XWikiUsers object).
Yet another detail, puzzling though it may be, is that of the objects in the original, one of them is the one defined in the xwiki-db-0.9.2.sql database download as an object of XWiki class XWiki.XWikiRights with ID 165499024, with a field named "levelsye". It's one of two XWiki.XWikiRights objects attached to a user profile document by createUser; the other one explicitly gives edit permission to the user himself. No other XWiki.XWikiRights objects contain this field, nor does the current definition of the XWiki.XWikiRights class contain it; instead they contain a field called "levels".
So, the questions are, in order of (logarithmically) decreasing importance:
1. How can I make this work?
I'll revert the question. Which version of XWiki are you using and where are you running the copyDocument (inside a wiki page or in an external application ?) I'm a little surprised that you are having problems. I suspect creating the new document worked but it was not saved correctly to the database nor the document was shared with other users. Are you getting any error message ?
2. Does a user profile document have some special status that makes it inappropriate to make a copy?
No
3. Is the "levelsye" field in an object simply a bug, or is there some arcane reason for its existence?
It's a bug. It might have an effect on copying this exact object.
Brian M. Thomas - Senior Technical Architect AT&T Services, Inc. One SBC Center, Room 24D3 St. Louis, MO 63101 314 235 3141
----------------------------------------------------------------------
--
-- You receive this message as a subscriber of the xwiki-users@objectweb.org mailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
More misery: I stopped the server, whipped out some quick SQL to replace the bogus field names, and restarted it. Result: bunches of complaints from documents all over the place that the "levelsye" field couldn't be saved. Of course, because the field name is a primary key component, just changing it is forbidden, so the script went more like this: create temporary table tmpstrings like xwikistrings; insert into tmpstrings select xws_id, "levels", xws_value from xwikistrings where xws_name = "levelsye"; insert ignore into xwikistrings select * from tmpstrings; delete from xwikistrings where xws_name = "levelsye"; Somehow, xwiki is remembering stuff it should have forgotten... brain[sic]
-----Original Message----- From: THOMAS, BRIAN M (SBCSI) Sent: Wednesday, May 31, 2006 9:29 AM To: xwiki-users@objectweb.org Subject: RE: [xwiki-users] $xwiki.copyDocument, objects, and cache
Thanks again, Ludovic, for a quick reply.
I apologize for neglecting to give you the version; I'm using 0.9.840, and calling copyDocument from a Velocity script on a wiki page. And no, I'm not getting any error messages, either on the page or in the logs, with one exception: my attempts to delete the incorrectly-copied document evoked an error message, which I didn't interpret as having to do with the objects but complained of an inconsistency in item counts (e.g. expected 1, found 0) or something similar; sorry I don't have the message now. After flushing, however, the deletion succeeded.
Your suspicions sound consistent with what I've seen here.
There's an update to this: I edited the original document's page permissions to add "admin, programming" to the "levels" field of the corrupted rights object, which was for XWiki.XWikiAdminGroup, and the objects survived the flush. Apparently the bogus fieldname (or, more likely, the lack of the correct one) is in some way the culprit - such as causing the transaction to abort when an object with an incorrect schema was saved. Why the document and its content (an #includeForm directive) survived the aborted transaction is a mystery in that case.
So, conjecturally, (apart from the incorrect DB data) the bug, if any, is that a) no error message ensued from an aborted transaction (I'm pretty sure, though not absolutely, that the logs were silent) and b) the cache was not cleared. I am adding an $xwiki.flushCache() call to the end of my copy script, at any rate, to be sure that I'm not fooled again by objects that aren't really there.
At a minimum, the database dump needs to be fixed ASAP...
brain[sic]
-----Original Message----- From: Ludovic Dubost [mailto:ludovic@xwiki.com] Sent: Tuesday, May 30, 2006 5:25 PM To: xwiki-users@objectweb.org Subject: Re: [xwiki-users] $xwiki.copyDocument, objects, and cache
Hi,
THOMAS, BRIAN M (SBCSI) a écrit :
When copying a document using $xwiki.copyDocument(), I find that all the attached objects are copied along with the document, and I am able to view them appropriately. However, they are not available to other users, and when I call $xwiki.flushCache(), only the document content remains; the objects are no longer attached.
A further detail, whether relevant or not, is that the document being copied is a user profile document (defined as a document named XWiki.<username>, where <username> is the login name of the user, and containing an XWiki.XWikiUsers object).
Yet another detail, puzzling though it may be, is that of the objects in the original, one of them is the one defined in the xwiki-db-0.9.2.sql database download as an object of XWiki class XWiki.XWikiRights with ID 165499024, with a field named "levelsye". It's one of two XWiki.XWikiRights objects attached to a user profile document by createUser; the other one explicitly gives edit permission to the user himself. No other XWiki.XWikiRights objects contain this field, nor does the current definition of the XWiki.XWikiRights class contain it; instead they contain a field called "levels".
So, the questions are, in order of (logarithmically) decreasing importance:
1. How can I make this work?
I'll revert the question. Which version of XWiki are you using and where are you running the copyDocument (inside a wiki page or in an external application ?) I'm a little surprised that you are having problems. I suspect creating the new document worked but it was not saved correctly to the database nor the document was shared with other users. Are you getting any error message ?
2. Does a user profile document have some special status that makes it inappropriate to make a copy?
No
3. Is the "levelsye" field in an object simply a bug, or is there some arcane reason for its existence?
It's a bug. It might have an effect on copying this exact object.
Brian M. Thomas - Senior Technical Architect AT&T Services, Inc. One SBC Center, Room 24D3 St. Louis, MO 63101 314 235 3141
----------------------------------------------------------------------
--
-- You receive this message as a subscriber of the xwiki-users@objectweb.org mailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
This message revisits a problem I had about a month ago. Time pressure prevented my investigating this further, but I now believe I have a firm handle on the problem, as well as more information and a question. First, a synopsis (original thread started at 5/30/2006 with the same subject line): I was unable to use $xwiki.copyDocument successfully, because an XWiki.XWikiRights object for XWiki.XWikiAdminGroup contained a bogus field named 'levelsye' instead of 'levels' as the object description shows. This caused an aborted transaction when saving the new document, which was not logged, complicating the debugging process. Further, the entire document save did not abort, leaving a new document with its content but no objects. Since the documents being copied were user profile documents, this was slightly problematic, to say the least. Unable to get the scripts to work (this was an attempt to migrate the wiki to a different authentication scheme, requiring a different standard for user names), we then simply created new users and bulk updated the database to replace all references to their old names with the new versions, and everything was fine. I had confirmed that the bogus fieldname was the problem by adding a rights object by hand, which of course had the correct schema, and deleting the old one. The document copy worked correctly, objects and all. So I went into the database to change all the bogus fieldnames in xwikistrings (which required deleting and re-adding, since the name participates in its primary key). That's when all kinds of things started breaking. I got an error saying (roughly) that there was no instance of the 'levelsye' field for the object being saved(and I wasn't saving any objects that I knew of), so I re-added them and let it alone. Since then, having delved further into the database schema, I realized that the problem was that, because XWiki saves the schema by which an object was created, there was yet another place I hadn't found where the errant fieldname was stored - xwikiproperties. Interestingly, a note by Robin Fernandez in a Feb 19 query on the email notification plugin showed this bogus property in his database, and he noted problems with saving a document... Finally, on looking at the code, I have discovered that the 'levelsye' fieldname is not only found in the database, but it is created by XWiki.ProtectUserPage, which is called by createUser. Ludovic confirmed that the database content was indeed a bug, so it looks like I have the following bugs to report: 1. The database load for 0.9.840 has 'levelsye' in several places, which should be 'levels'; 2. com.xpn.xwiki.XWiki.ProtectUserPage() perpetuates this error. When copying objects fails as a result of the above, copyDocument 3. incorrectly returns success; 4. does not log the failure; 5. does not back out the transaction that created the copy, leaving an improper copy of the document which looks correct to the user who called copyDocument() because 6. the cache is not refreshed. The question: is this correct, and if so should I report these bugs as one, as six, or something in between? brain[sic]
participants (2)
-
Ludovic Dubost -
THOMAS, BRIAN M (SBCSI)