Re: [galaxy-dev] Error when adding datasets

On 04/15/2011 10:56 AM, Louise-Amélie Schmitt wrote: > 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? > the folder where you keep the datasets, eg: <your local path>/galaxy_dist/database/ and it particular <your local path>/galaxy_dist/database/files/000/dataset_*.dat if you have an empty PostgreSQL database, then there should also be no datasets. Hans >> >> - 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/ > >