[galaxy-dev] Error when adding datasets
Nate Coraor
nate at bx.psu.edu
Thu Jun 2 11:48:55 EDT 2011
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 for 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 panel.
> >
> > 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 at bx.psu.edu>
> > 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 new
> >>>> database, and they would all be empty. When you first registered as
> >>>> the admin user, it would have automatically populated several tables
> >>>> with data, including the history table. One or more of these things
> >>>> 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 changes,
> >>>> 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 scrolling 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 back
> >>>>>> 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 database?
> >>>>>>
> >>>>>
> >>>>> 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 hg
> >>>>> 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 problem
> >>>>>>> but he
> >>>>>>> got no answer:
> >>>>>>> http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-May/002732.html
> >>>>>>>
> >>>>>>> Here is the error message I get when clicking the "Add datasets"
> >>>>>>> button
> >>>>>>> in a library, in the admin's "Manage data libraries" panel:
> >>>>>>>
> >>>>>>>
> >>>>>>> UnmappedInstanceError: Class '__builtin__.NoneType' is not
> >>>>>>> mapped
> >>>>>>>
> >>>>>>> URL:
> >>>>>>>
> > http://manni/galaxy/library_common/upload_library_dataset?library_id=f2db41e1fa331b3e&show_deleted=False&cntrller=library_admin&folder_id=f2db41e1fa331b3e&use_panels=False
> >>>>>>> File
> >>>>>>>
> > '/g/funcgen/galaxy/eggs/WebError-0.8a-py2.6.egg/weberror/evalexception/middleware.py',
> >>>>>>> line 364 in respond
> >>>>>>> app_iter = self.application(environ, detect_start_response)
> >>>>>>> File
> >>>>>>> '/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/debug/prints.py',
> >>>>>>> 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
> >>>>>>> '/g/funcgen/galaxy/eggs/Paste-1.6-py2.6.egg/paste/recursive.py',
> >>>>>>> line 80 in __call__
> >>>>>>> return self.application(environ, start_response)
> >>>>>>> File
> >>>>>>>
> > '/g/funcgen/galaxy/lib/galaxy/web/framework/middleware/remoteuser.py',
> >>>>>>> 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
> >>>>>>> '/g/funcgen/galaxy/lib/galaxy/web/controllers/library_common.py',
> >>>>>>> line 907 in upload_library_dataset
> >>>>>>> trans.sa_session.refresh( history )
> >>>>>>> File
> >>>>>>>
> > '/g/funcgen/galaxy/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/orm/scoping.py',
> >>>>>>> line 127 in do
> >>>>>>> return getattr(self.registry(), name)(*args, **kwargs)
> >>>>>>> File
> >>>>>>>
> > '/g/funcgen/galaxy/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/orm/session.py',
> >>>>>>> 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 at 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 at bx.psu.edu
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> Greg Von Kuster
> >> Galaxy Development Team
> >> greg at bx.psu.edu
>
> Greg Von Kuster
> Galaxy Development Team
> greg at bx.psu.edu
>
>
>
>
More information about the galaxy-dev
mailing list