Re: [galaxy-dev] Error when adding datasets

Greg Von Kuster wrote: > Hello Louise, > > I've CC'd Nate on this as he may be able to help - although no > guarantees. I'm not expert enough in this area to know where to look

> the cause. Perhaps someone in the community can help as well. > > It is likely that LDAP is playing a role in this behavior. > > > On Apr 14, 2011, at 1:00 PM, Louise-Amélie Schmitt wrote: > > > The thing is, we use LDAP logging so we can't even access the website > > without logging in. > > Moreover, when I logged in, I arrived on the data analysis page where > > the > > automatic "unnamed history" was obviously created in the history

> > > > I forgot to mention we have issues creating and deleting histories, > > like, > > we can't access some histories and everytime we delete histories, two > > extra > > unnamed histories are created. As I mentioned before, it is also > > impossible > > to load a dataset in any history, existing or not. Okay, somehow I missed all the followup on this question when I committed a fix a few minutes ago. Could you provide some details about the inaccessible histories (what happens when you try to access them, traceback, etc?) and loading data - you mean the upload tool fails? Is there also a traceback here?

Thanks, --nate > > > > Do you think it could be linked to our using LDAP? > > > > Thanks > > L-A > > > > > > On Thu, 14 Apr 2011 12:06:55 -0400, Greg Von Kuster <greg(a)bx.psu.edu&gt; > > wrote: > >> On Apr 14, 2011, at 11:49 AM, Louise-Amélie Schmitt wrote: > >> > >>> Here is the result I got from the debug statements: > >>> > >>> galaxy.web.controllers.library_common DEBUG 2011-04-14 17:46:02,286 > >>> ### > >>> history: None > >> > >> This is the problem - when you registered normally, a history would > >> have > >> been automatically created for you. But somehow you don't have a > > history - > >> no idea why / how this happened, but it is very unlikely this is a > > result > >> of a bug within Galaxy. Try logging out and logging in again and a > >> new > >> history should be created for you. > >> > >> > >>> galaxy.web.controllers.library_common DEBUG 2011-04-14 17:46:02,286 > >>> ### > >>> trans: <galaxy.web.framework.GalaxyWebUITransaction object at > >>> 0x29f40950> > >>> galaxy.web.controllers.library_common DEBUG 2011-04-14 17:46:02,286 > >>> ### > >>> trans.sa_session: <sqlalchemy.orm.scoping.ScopedSession object at > >>> 0x19ab21d0> > >>> > >>> Thanks again > >>> L-A > >>> > >>> > >>> Le jeudi 14 avril 2011 à 11:05 -0400, Greg Von Kuster a écrit : > >>>> I assume when you dropped the old database and recreated the new, > >>>> empty database, you made sure the database connection string in > >>>> universe_wsgi.ini was correctly set. if so, when you started up > >>>> Galaxy, it would have created all of the required tables in the

> >>>> database, and they would all be empty. When you first registered

> >>>> the admin user, it would have automatically populated several

> >>>> with data, including the history table. One or more of these

> >>>> must not have been successful. > >>>> > >>>> > >>>> To attempt to narrow down the problem, I'll need you to do the > >>>> following. Here are lines # 905 - 907 in > >>>> ~/lib/galaxy/web/controllers/library-common.py > >>>> > >>>> > >>>> # Send the current history to the form to enable importing > >>>> datasets from history to library > >>>> history = trans.get_history() > >>>> trans.sa_session.refresh( history ) > >>>> > >>>> > >>>> Please add the following debug statements: > >>>> > >>>> > >>>> # Send the current history to the form to enable importing > >>>> datasets from history to library > >>>> history = trans.get_history() > >>>> log.debug("### history: %s" % str( history )) > >>>> log.debug("### trans: %s" % str( trans )) > >>>> log.debug("### trans.sa_session: %s" % > >>>> str( trans.sa_session )) > >>>> trans.sa_session.refresh( history ) > >>>> > >>>> > >>>> Stop and restart your Galaxy server after making the above

> >>>> and reply back with the output of the debug statements. Assuming > >>>> you > >>>> start your Galaxy instance with: > >>>> > >>>> > >>>> sh run.sh > >>>> > >>>> > >>>> you'll see the results of the debug statements in the log

> >>>> in > >>>> the window in which you started Galaxy. > >>>> > >>>> > >>>> Thanks > >>>> > >>>> > >>>> On Apr 14, 2011, at 10:46 AM, Louise-Amélie Schmitt wrote: > >>>> > >>>>> Hello Greg > >>>>> > >>>>> Thank you for answering. Please find the answers after each > >>>>> question. > >>>>> > >>>>> > >>>>> Le jeudi 14 avril 2011 à 10:19 -0400, Greg Von Kuster a écrit : > >>>>>> Hello Louise, > >>>>>> > >>>>>> I do not think this issue is related to the Galaxy eggs, but > >>>>>> instead looks like a data issue of some kind. Please replly

> >>>>>> with answers to the following questions. > >>>>>> > >>>>>> How did you create your database? > >>>>> > >>>>> Couldn't have done it more simply ^^: > >>>>> CREATE DATABASE "galaxy_db"; > >>>>> GRANT ALL ON DATABASE "galaxy_db" TO "galaxy"; > >>>>> executed in psql. > >>>>> The very same way I did for the one that's still working fine. > >>>>> > >>>>>> Did you populate it with any data exported from another

> >>>>>> > >>>>> > >>>>> In the beginning yes but when I saw that error I dropped the > >>>>> database > >>>>> and re-created it again, to start anew and test on an empty > >>>>> database. I > >>>>> even created a brand new test database to see if the issue wasn't > >>>>> related to stuff remaining after dropping the database, but it > >>>>> turned > >>>>> out badly too. > >>>>> > >>>>>> What version of Galaxy are you using? > >>>>> > >>>>> The latest dist, cause when I saw how things were turning out I

> >>>>> pulled and updated hoping it would fix the issue. I did that this > >>>>> morning. > >>>>> > >>>>>> What database are you using? > >>>>> > >>>>> PostgreSQL, as recommended in the doc. > >>>>> > >>>>>> > >>>>>> Greg Von Kuster > >>>>> > >>>>> Cheers, > >>>>> L-A > >>>>> > >>>>>> > >>>>>> On Apr 14, 2011, at 5:38 AM, Louise-Amélie Schmitt wrote: > >>>>>> > >>>>>>> Hello everyone > >>>>>>> > >>>>>>> I have an issue when trying to import new datasets or when > >>>>>>> putting a > >>>>>>> dataset into a history. I saw Edward Kirton had the same

> >>>>>>> but he > >>>>>>> got no answer: > >>>>>>>

> >>>>>>> > >>>>>>> Here is the error message I get when clicking the "Add

> >>>>>>> button > >>>>>>> in a library, in the admin's "Manage data libraries" panel: > >>>>>>> > >>>>>>> > >>>>>>> UnmappedInstanceError: Class '__builtin__.NoneType' is not > >>>>>>> mapped > >>>>>>> > >>>>>>> URL: > >>>>>>> > >

> >>>>>>> File > >>>>>>> > >

> >>>>>>> line 364 in respond > >>>>>>> app_iter = self.application(environ, detect_start_response) > >>>>>>> File > >>>>>>>

> >>>>>>> line 98 in __call__ > >>>>>>> environ, self.app) > >>>>>>> File > >>>>>>> '/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/wsgilib.py', > >>>>>>> line > >>>>>>> 539 in intercept_output > >>>>>>> app_iter = application(environ, replacement_start_response) > >>>>>>> File > >>>>>>>

> >>>>>>> File > >>>>>>> > >

> >>>>>>> line 109 in __call__ > >>>>>>> return self.app( environ, start_response ) > >>>>>>> File > >>>>>>> > > '/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', > >>>>>>> line 632 in __call__ > >>>>>>> return self.application(environ, start_response) > >>>>>>> File '/g/funcgen/galaxy/lib/galaxy/web/framework/base.py', line > >>>>>>> 145 in > >>>>>>> __call__ > >>>>>>> body = method( trans, **kwargs ) > >>>>>>> File > >>>>>>>

> >>>>>>> File > >>>>>>> > >

> >>>>>>> File > >>>>>>> > >

> >>>>>>> line 925 in refresh > >>>>>>> raise exc.UnmappedInstanceError(instance) > >>>>>>> UnmappedInstanceError: Class '__builtin__.NoneType' is not > >>>>>>> mapped > >>>>>>> > >>>>>>> > >>>>>>> Now when does it occur: > >>>>>>> > >>>>>>> I have two databases. One test database I created a month ago > >>>>>>> which > >>>>>>> works fine, even now. The other one I created recently which is > >>>>>>> supposed > >>>>>>> to be the final database. But the latter keeps triggering the > >>>>>>> above > >>>>>>> message, even when I drop it and create it all over again. I > >>>>>>> even tried > >>>>>>> to create a third one, all clean and new but the problem > >>>>>>> remains. I > >>>>>>> tried to trash all the eggs so Galaxy gets fresh new eggs, with > >>>>>>> no > >>>>>>> effect at all. The error's still there. > >>>>>>> > >>>>>>> If you have any clue, I'll be forever grateful. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> L-A > >>>>>>> > >>>>>>> ___________________________________________________________ > >>>>>>> Please keep all replies on the list by using "reply all" > >>>>>>> in your mail client. To manage your subscriptions to this > >>>>>>> and other Galaxy lists, please use the interface at: > >>>>>>> > >>>>>>> http://lists.bx.psu.edu/ > >>>>>> > >>>>>> Greg Von Kuster > >>>>>> Galaxy Development Team > >>>>>> greg(a)bx.psu.edu > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> ___________________________________________________________ > >>>>> Please keep all replies on the list by using "reply all" > >>>>> in your mail client. To manage your subscriptions to this > >>>>> and other Galaxy lists, please use the interface at: > >>>>> > >>>>> http://lists.bx.psu.edu/ > >>>>> > >>>>> > >>>> > >>>> Greg Von Kuster > >>>> Galaxy Development Team > >>>> greg(a)bx.psu.edu > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> Greg Von Kuster > >> Galaxy Development Team > >> greg(a)bx.psu.edu > > Greg Von Kuster > Galaxy Development Team > greg(a)bx.psu.edu > > > >