On Thu, 2 Jun 2011 11:48:55 -0400, Nate Coraor <nate(a)bx.psu.edu> wrote:
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?
ooh it's been a while I haven't seen the issue since I not-so-elegantly
avoided the problem making our two instances run on separate machines.
But I'll try to answer your question as accurately as I can.
I experienced a similar error (pretty much the same traceback as the one I
pasted in a previous message, just yelling at me saying that the history is
nonexistent) whenever I tried to:
- upload data in the manage libraries admin panel and in the analyse data
panel (upload tool)
- load an already uploaded dataset in any kind of history (saved or new)
- probably do something else, I can't really remember
I also had issues dealing with histories but not getting any traceback,
like I mentioned a little lower: Everytime I tried to delete any number of
histories, the histories were deleted but two were created.
I hope this will help, sorry I can't really be more precise.
L-A
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>
> > 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
>
>
>
>