Closed GoogleCodeExporter closed 8 years ago
I have the same problem. If you refresh the page you can see that the column
was indeed deleted, but it's a very annoying bug nonetheless.
Original comment by andrewm....@gmail.com
on 26 Dec 2010 at 9:09
What browsers do you guys see this problem with?
Original comment by tfmorris
on 26 Dec 2010 at 9:47
I'm using Chrome. How about you hbechmann?
Original comment by andrewm....@gmail.com
on 26 Dec 2010 at 10:21
I have tried several XML files, but I can't reproduce this with WinXP + Chrome
9 + Refine 2. Could one of you guys post a (masked) copy of your XML file,
please?
Original comment by GabrielS...@gmail.com
on 28 Dec 2010 at 3:50
I'm actually using Chrome 8 (The stable verison.) but I doubt switching to 9
would make much of a difference. Anyway, here's the XML file I started with:
http://ajedi32.webs.com/ged2.xml
Original comment by andrewm....@gmail.com
on 28 Dec 2010 at 5:01
I too see this; I'm using Chrome 12.0.742.9 dev and Firefox 3.6.16, both on Mac
OS X 10.6.7.
It's 100% repeatable after importing all my XML files, and occurs on the sixth
column-related action (either a column deletion or a column move, in my case).
In other words, I can delete five columns successfully -- and then on the sixth
column deletion (or move), I get the aforementioned Javascript alert box that
reads something to the effect of "index: X; size: Y". This bug persists even
after I reload the web page containing the data set; specifically, once Refine
is in the state where I'm getting the Javascript alert box, then after a page
reload, I get the Javascript alert box on the very first column-related action
(in other words, I don't have a five-success window before the alerts start
coming up).
I am running Refine v2.0 [r1836], downloaded this morning.
Original comment by ja...@queso.com
on 26 Apr 2011 at 2:29
Also of note, once Refine gets into the state where it's throwing Javascript
alert boxes for column-related actions, then it no longer applies actions to
the undo/redo buffer -- so any column-related actions that generate the alerts
are un-undoable (and unextractable).
Original comment by ja...@queso.com
on 26 Apr 2011 at 2:32
And another data point: I just downloaded the latest dev trunk and am running
it, and the bug still exists. This time, I got 11 successful column deletions
before the 12th triggered the bug; the alert read "Index: 70; size: 69", and
the console window read:
java.lang.IndexOutOfBoundsException: Index: 70, Size: 69
at java.util.LinkedList.entry(LinkedList.java:365)
at java.util.LinkedList.get(LinkedList.java:315)
at com.google.refine.model.RecordModel.computeKeyedGroups(RecordModel.java:194)
at com.google.refine.model.RecordModel.update(RecordModel.java:112)
at com.google.refine.model.Project.update(Project.java:255)
at com.google.refine.model.changes.ColumnRemovalChange.apply(ColumnRemovalChange.java:75)
at com.google.refine.history.HistoryEntry.apply(HistoryEntry.java:127)
at com.google.refine.history.History.addEntry(History.java:131)
at com.google.refine.process.QuickHistoryEntryProcess.performImmediate(QuickHistoryEntryProcess.java:71)
at com.google.refine.process.ProcessManager.queueProcess(ProcessManager.java:69)
at com.google.refine.commands.Command.performProcessAndRespond(Command.java:214)
at com.google.refine.commands.column.RemoveColumnCommand.doPost(RemoveColumnCommand.java:62)
at com.google.refine.RefineServlet.service(RefineServlet.java:171)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:81)
at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:132)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Hope this is helpful.
Original comment by ja...@queso.com
on 26 Apr 2011 at 2:42
Original comment by dfhu...@gmail.com
on 27 Apr 2011 at 12:07
Import this data and then try deleting the both of the columns labeled "type".
Then, rename the remaining columns "gname" and cname". All the changes that I
have made after these initial changes have not been recorded in the "undo/redo"
list! Plus, I continue to get the message "Error: Index 4 size 3"
Original comment by alexande...@gmail.com
on 2 Jun 2011 at 7:54
Attachments:
Fixed in trunk/ by r2077, verified by using the file sparql (1).json.
Original comment by dfhu...@gmail.com
on 5 Jun 2011 at 4:35
Original comment by tfmorris
on 9 Jun 2011 at 7:58
Original issue reported on code.google.com by
hbechm...@gmail.com
on 11 Nov 2010 at 10:23