Re: [galaxy-dev] Error when adding datasets

Hi Hans, thanks for your reply. > > - is your PostgreSQL database in sync with the database folder? I'm sorry I'm not sure I get what you mean, what folder is it?

> > - are you sure there is no second galaxy installation accessing the > same PostgreSQL database? Never been this sure of something before. :) I installed both galaxy and postgresql myself so I can guarantee there's ony one galaxy install on it. > > - you mention, that you have started with an empty PostgreSQL > database, so this last question does probably not apply: make sure > you have the right user names (you even run into trouble with case > sensitivity) in your PostgreSQL database. We had troubles when we > switched to external authentication: some users just couldn't work > anymore, ie could not create new history items anymore. The problem > was then solved by fixing their user names in the (MySQL) database. Yes, the username is properly created in the database when I log in on an empty database. We never used anything besides LDAP anyway. > > Regards, Hans Cheers, L-A > > > >> >> 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. >>> >>> 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&lt;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 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=f2db... >>>>>>>>> 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(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 >> >> >> >> >> ___________________________________________________________ >> 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/