You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthew B. <mat...@ou...> - 2006-03-21 09:53:30
|
Colin Tatham wrote: > Matthew Buckett wrote: >> Peter Crowther wrote: >>> 3. Bite the bullet, throw away the homebrew XML repository and use >>> somebody else's work. My candidate would be eXist, which has much of >>> this functionality already built in to XQuery. >> >> >> For real flexible searching use something specifically for it like >> Lucene http://lucene.apache.org/java/docs/ >> >> I see moving to eXist for XML storage as a related but different >> issue, at the moment it happens that the XML storage is use for >> searching but we may find this limiting in the future if the XML >> structure doesn't lead to the searches we need. > > Problem with using Lucene is that it'll need to keep its own index of > words, which will have to kept in synch with Bod. By using an XML > database (replacing Bods) we get good searching, don't have to synch it, > and it'll be better as managing the metadata as XML for import/export, etc I think syncing data for good search in inevitable. At the moment we already sync data. The resource title and description end up in both the xml tables and in the resource tables. I'm not suggesting that we use Lucene for storing XML data, just for search data which might have orginally been in XML. This is why I think switching from XMLRespository is a slightly different issue to improving the search although they do overlap at the moment. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Colin T. <col...@ou...> - 2006-03-21 09:38:36
|
Matthew Buckett wrote: > Peter Crowther wrote: >> 3. Bite the bullet, throw away the homebrew XML repository and use >> somebody else's work. My candidate would be eXist, which has much of >> this functionality already built in to XQuery. > > > For real flexible searching use something specifically for it like > Lucene http://lucene.apache.org/java/docs/ > > I see moving to eXist for XML storage as a related but different issue, > at the moment it happens that the XML storage is use for searching but > we may find this limiting in the future if the XML structure doesn't > lead to the searches we need. Problem with using Lucene is that it'll need to keep its own index of words, which will have to kept in synch with Bod. By using an XML database (replacing Bods) we get good searching, don't have to synch it, and it'll be better as managing the metadata as XML for import/export, etc Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Matthew B. <mat...@ou...> - 2006-03-21 09:19:03
|
Peter Crowther wrote: >> From: Colin Tatham >> I think there are two possible approaches: >> >> 1. Use regular expressions to find possible matches of the >> search term >> in the identical_table Hashtable keys, or >> >> 2. Execute an SQL query with wildcards on the table that contains the >> tokens. > > 3. Bite the bullet, throw away the homebrew XML repository and use > somebody else's work. My candidate would be eXist, which has much of > this functionality already built in to XQuery. For real flexible searching use something specifically for it like Lucene http://lucene.apache.org/java/docs/ I see moving to eXist for XML storage as a related but different issue, at the moment it happens that the XML storage is use for searching but we may find this limiting in the future if the XML structure doesn't lead to the searches we need. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Atif S. <BM...@bm...> - 2006-03-16 14:05:23
|
Congratulations. :-) >>Hello, >> >>I'm not about reading email very much as Colin mentioned, as Anna gave birth to >>a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both mother and >>baby are doing well. A few picture are up for those who are interested: >> >>http://flickr.com/photos/buckett/sets/72057594079827183/ >> >>Matthew >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by xPML, a groundbreaking scripting language >>that extends applications into web and mobile media. Attend the live webcast >>and join the prime developer group breaking into this new coding territory! >>http://sel.as-us.falkag.net/sel?cmd >>_______________________________________________ >>Bodington-developers mailing list >>Bod...@li... >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> >> > > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > >. > > > |
From: Brian P. C. <bm...@bm...> - 2006-03-16 13:19:55
|
Way to go, Papa Buckett. Congratulations. Brian > Hello, > > I'm not about reading email very much as Colin mentioned, as Anna gave birth to > a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both mother and > baby are doing well. A few picture are up for those who are interested: > > http://flickr.com/photos/buckett/sets/72057594079827183/ > > Matthew > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
From: Antony C. <an...@sm...> - 2006-03-15 18:10:36
|
Congratulations to all Matthew - if you have trouble sleeping try=20 refactoring Facility! Cheers, Antony On 15 Mar 2006, at 13:51, Matthew Buckett wrote: > Hello, > > I'm not about reading email very much as Colin mentioned, as Anna gave=20= > birth to > a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both=20 > mother and > baby are doing well. A few picture are up for those who are = interested: > > http://flickr.com/photos/buckett/sets/72057594079827183/ > > Matthew > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting=20 > language > that extends applications into web and mobile media. Attend the live=20= > webcast > and join the prime developer group breaking into this new coding=20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Andrew B. <a.g...@le...> - 2006-03-15 14:36:24
|
Not going to tell you. Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Alistair Young Sent: 15 March 2006 14:07 To: bod...@li... Subject: Re: [Bodington-developers] OT: Not reading email much.... ah! a fellow lurker :) long time no speak Michael. Let's start a new =20 list - bodington-lurkers and not post to it! anyone else want to join =20 it? Alistair On 15 Mar 2006, at 14:03, M Thomas wrote: > Excellent news, congratulations! > > > On 15/03/06, Matthew Buckett <mat...@ou...> wrote: >> Hello, >> >> I'm not about reading email very much as Colin mentioned, as Anna =20 >> gave birth to >> a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. =20 >> Both mother and >> baby are doing well. A few picture are up for those who are =20 >> interested: >> >> http://flickr.com/photos/buckett/sets/72057594079827183/ >> >> Matthew >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 >> language >> that extends applications into web and mobile media. Attend the =20 >> live webcast >> and join the prime developer group breaking into this new coding =20 >> territory! >> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > > > -- > m.cha3l > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting = language that extends applications into web and mobile media. Attend the live = webcast and join the prime developer group breaking into this new coding = territory! http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Andrew B. <a.g...@le...> - 2006-03-15 14:35:10
|
Matthew Congratulations. Hope you and Anna get some sleep! Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of Matthew Buckett Sent: 15 March 2006 13:51 To: bod...@li... Subject: [Bodington-developers] OT: Not reading email much.... Hello, I'm not about reading email very much as Colin mentioned, as Anna gave = birth to a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both = mother and baby are doing well. A few picture are up for those who are interested: http://flickr.com/photos/buckett/sets/72057594079827183/ Matthew ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting = language that extends applications into web and mobile media. Attend the live = webcast and join the prime developer group breaking into this new coding = territory! http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: M T. <m....@gm...> - 2006-03-15 14:14:53
|
:) +1 On 15/03/06, Alistair Young <ali...@sm...> wrote: > ah! a fellow lurker :) long time no speak Michael. Let's start a new > list - bodington-lurkers and not post to it! anyone else want to join > it? > > Alistair > > On 15 Mar 2006, at 14:03, M Thomas wrote: > > > Excellent news, congratulations! > > > > > > On 15/03/06, Matthew Buckett <mat...@ou...> wrote: > >> Hello, > >> > >> I'm not about reading email very much as Colin mentioned, as Anna > >> gave birth to > >> a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. > >> Both mother and > >> baby are doing well. A few picture are up for those who are > >> interested: > >> > >> http://flickr.com/photos/buckett/sets/72057594079827183/ > >> > >> Matthew > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by xPML, a groundbreaking scripting > >> language > >> that extends applications into web and mobile media. Attend the > >> live webcast > >> and join the prime developer group breaking into this new coding > >> territory! > >> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > >> _______________________________________________ > >> Bodington-developers mailing list > >> Bod...@li... > >> https://lists.sourceforge.net/lists/listinfo/bodington-developers > >> > > > > > > -- > > m.cha3l > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language > > that extends applications into web and mobile media. Attend the > > live webcast > > and join the prime developer group breaking into this new coding > > territory! > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=12164= 2 > > _______________________________________________ > > Bodington-developers mailing list > > Bod...@li... > > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > -- m.cha3l |
From: Alistair Y. <ali...@sm...> - 2006-03-15 14:06:34
|
ah! a fellow lurker :) long time no speak Michael. Let's start a new =20 list - bodington-lurkers and not post to it! anyone else want to join =20= it? Alistair On 15 Mar 2006, at 14:03, M Thomas wrote: > Excellent news, congratulations! > > > On 15/03/06, Matthew Buckett <mat...@ou...> wrote: >> Hello, >> >> I'm not about reading email very much as Colin mentioned, as Anna =20 >> gave birth to >> a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. =20 >> Both mother and >> baby are doing well. A few picture are up for those who are =20 >> interested: >> >> http://flickr.com/photos/buckett/sets/72057594079827183/ >> >> Matthew >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20= >> language >> that extends applications into web and mobile media. Attend the =20 >> live webcast >> and join the prime developer group breaking into this new coding =20 >> territory! >> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > > > -- > m.cha3l > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: M T. <m....@gm...> - 2006-03-15 14:03:44
|
Excellent news, congratulations! On 15/03/06, Matthew Buckett <mat...@ou...> wrote: > Hello, > > I'm not about reading email very much as Colin mentioned, as Anna gave bi= rth to > a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both mothe= r and > baby are doing well. A few picture are up for those who are interested: > > http://flickr.com/photos/buckett/sets/72057594079827183/ > > Matthew > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > -- m.cha3l |
From: Peter C. <Pet...@me...> - 2006-03-15 14:02:33
|
> From: Matthew Buckett > Anna gave birth to a baby boy called Wilf J Buckett > (6lb 12) on Friday at 10:13. Both mother and > baby are doing well. Congratulations, and best wishes to all of you. - Peter |
From: Peter C. <Pet...@me...> - 2006-03-15 14:00:25
|
> From: Matthew Buckett > Nulls don't end up in the index on PostgreSQL Ah. Oh. Oh dear. > Sounds like this is a PostgreSQL/MSSQL/HSQLDB difference. It is. Not sure whether / which way ANSI mandates this, but (as we've seen) the behaviour cannot be relied upon. - Peter |
From: Alistair Y. <ali...@sm...> - 2006-03-15 13:57:45
|
congrats indeed old boy, to you and the missus :) pipe and slippers =20 soon for you ;) Alistair On 15 Mar 2006, at 13:51, Matthew Buckett wrote: > Hello, > > I'm not about reading email very much as Colin mentioned, as Anna =20 > gave birth to > a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both =20= > mother and > baby are doing well. A few picture are up for those who are =20 > interested: > > http://flickr.com/photos/buckett/sets/72057594079827183/ > > Matthew > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Jon M. <jo...@te...> - 2006-03-15 13:57:43
|
Congratulations! Matthew Buckett wrote: >Hello, > >I'm not about reading email very much as Colin mentioned, as Anna gave birth to >a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both mother and >baby are doing well. A few picture are up for those who are interested: > >http://flickr.com/photos/buckett/sets/72057594079827183/ > >Matthew > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > |
From: Matthew B. <mat...@ou...> - 2006-03-15 13:51:16
|
Hello, I'm not about reading email very much as Colin mentioned, as Anna gave bi= rth to a baby boy called Wilf J Buckett (6lb 12) on Friday at 10:13. Both mothe= r and baby are doing well. A few picture are up for those who are interested: http://flickr.com/photos/buckett/sets/72057594079827183/ Matthew |
From: Matthew B. <mat...@ou...> - 2006-03-15 13:47:29
|
In message <441...@ou...> bod...@li... writes: > Jon Maber wrote: > > A change is needed urgently - removing the constraint would be the mo= st=20 > > obvious first step. Was there a bug report that led to the addition o= f=20 > > the constraint? Is there another way round that bug? >=20 > Matthew would have to answer that. We had a lot of problems with=20 > Uploaded File behaviour, most notably where they all disappear from the= =20 > display periodically, and our uploaded files table got itself pretty=20 > messed up. Matthew rewrote large chunks of code to sort that out, and=20 > we've had very few bug reports (they were fixed). We had duplicate files, appearing which is what this index is designed to= fix although the Java has also changed (belt and braces). > There is a difference between our version of the index and that on Bod: >=20 > Ours has the following: >=20 > CREATE UNIQUE INDEX uploaded_files_unq_name ON uploaded_files=20 > (parent_uploaded_file_id, name) > GO Nulls don't end up in the index on PostgreSQL so it allows multiple entri= es for the root. Sounds like this is a PostgreSQL/MSSQL/HSQLDB difference. > -- Only PostgreSQL supports partial indexes. > --CREATE UNIQUE INDEX uploaded_files_one_root ON uploaded_files=20 > (resource_id ) > -- WHERE parent_uploaded_file_id IS NULL > --GO This is to only allow one root folder for each resource as some of the re= source had two or more in our WebLearn deployment. Matthew |
From: Colin T. <col...@ou...> - 2006-03-15 13:37:29
|
Jon Maber wrote: > A change is needed urgently - removing the constraint would be the most > obvious first step. Was there a bug report that led to the addition of > the constraint? Is there another way round that bug? Matthew would have to answer that. We had a lot of problems with Uploaded File behaviour, most notably where they all disappear from the display periodically, and our uploaded files table got itself pretty messed up. Matthew rewrote large chunks of code to sort that out, and we've had very few bug reports (they were fixed). There is a difference between our version of the index and that on Bod: Ours has the following: CREATE UNIQUE INDEX uploaded_files_unq_name ON uploaded_files (parent_uploaded_file_id, name) GO -- Only PostgreSQL supports partial indexes. --CREATE UNIQUE INDEX uploaded_files_one_root ON uploaded_files (resource_id ) -- WHERE parent_uploaded_file_id IS NULL --GO Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Peter C. <Pet...@me...> - 2006-03-15 13:23:19
|
> From: bod...@li...=20 > [mailto:bod...@li...] On=20 > Behalf Of Jon Maber > What is the definition of the unique index=20 > 'uploaded_files_unq_name'? in=20 > your database Peter? To quote the database scripting tool on my SQL Server 2000 installation: CREATE UNIQUE INDEX [uploaded_files_unq_name] ON [bod].[uploaded_files]([parent_uploaded_file_id], [name]) ON [PRIMARY] - Peter |
From: Jon M. <jo...@te...> - 2006-03-15 13:14:40
|
The problem lies with the change to uploaded_files.sql which was checked in 3 weeks ago. It adds this unique index; CREATE UNIQUE INDEX uploaded_files_unq_name ON uploaded_files (parent_uploaded_file_id, name) GO This constraint is ok for files and sub folders because they all have a parent_uploaded_file_id but the root folder for each resource has a null parent_uploaded_file_id and always has the same name. Consequently this constraint is bound to prevent uploading of files to any new resource other than the first resource that files were uploaded to since installation. A change is needed urgently - removing the constraint would be the most obvious first step. Was there a bug report that led to the addition of the constraint? Is there another way round that bug? Jon |
From: Colin T. <col...@ou...> - 2006-03-15 13:08:37
|
Peter Crowther wrote: > If you get a chance, could you check the expected name on your (live or > test) install? It wouldn't surprise me if the name was set to the > resource ID, for example; that would be enough to disambiguate. Seems to set it to an empty string for the root folder, but I'll have a closer look... -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Jon M. <jo...@te...> - 2006-03-15 13:03:24
|
Peter Crowther wrote: >null parent ID and a blank name. It then fails because "Cannot insert >duplicate key row in object 'uploaded_files' with unique index >'uploaded_files_unq_name'". > > What is the definition of the unique index 'uploaded_files_unq_name'? in your database Peter? Jon Maber |
From: Peter C. <Pet...@me...> - 2006-03-15 12:58:31
|
> From: Colin Tatham > You need a root folder for each resource before you can=20 > upload anything. OK. > Without looking the code again, I think the null parent id indicates=20 > that it's the root folder for that resource. I don't remember=20 > it having a blank name... If you get a chance, could you check the expected name on your (live or test) install? It wouldn't surprise me if the name was set to the resource ID, for example; that would be enough to disambiguate. > Don't know if I'm being thick, but what are you trying to do?=20 Upload a file through the normal user interface to a pigeonhole; and the same for a logbook. Both of these while testing work I've done for Leeds. Both work for the first resource that contains uploaded files, and both fail for subsequent resources. - Peter |
From: Colin T. <col...@ou...> - 2006-03-15 12:37:17
|
Peter Crowther wrote: > This is probably one for Matthew. Matthew's on leave. He might want to elaborate with some pictures... > In summary: Is there one uploaded_files root (ie with a null parent) per > resource, or is there one total? Did something change with the > uploaded_files rewrite? There's some history with this, I encountered a problem when doing the copy code. You need a root folder for each resource before you can upload anything. Jon added a comment to the code about fixing it, Matthew did some more work on that more recently. > In detail: I'm trying to upload files from multiple resources (two > pigeonholes and one logbook). All works well while I am only uploading > from the first resource. As soon as I try to upload anything from a > second, the code tries to create a root folder for that resource with a > null parent ID and a blank name. Without looking the code again, I think the null parent id indicates that it's the root folder for that resource. I don't remember it having a blank name... > It then fails because "Cannot insert > duplicate key row in object 'uploaded_files' with unique index > 'uploaded_files_unq_name'". > > I've not changed the logbook code for a couple of years; it's used in > production, yet it also exhibits this behaviour. What am I missing? Don't know if I'm being thick, but what are you trying to do? Have you written some code to automate file uploads in multiple areas, or is this all through the usual interface? Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
From: Peter C. <Pet...@me...> - 2006-03-15 12:09:44
|
This is probably one for Matthew. In summary: Is there one uploaded_files root (ie with a null parent) per resource, or is there one total? Did something change with the uploaded_files rewrite? In detail: I'm trying to upload files from multiple resources (two pigeonholes and one logbook). All works well while I am only uploading from the first resource. As soon as I try to upload anything from a second, the code tries to create a root folder for that resource with a null parent ID and a blank name. It then fails because "Cannot insert duplicate key row in object 'uploaded_files' with unique index 'uploaded_files_unq_name'". I've not changed the logbook code for a couple of years; it's used in production, yet it also exhibits this behaviour. What am I missing? - Peter |