Louise-Amélie Schmitt wrote:
> 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.
When these were running on the same machine, were they both served as
seperate directories under the same hostname? If so, did you set
cookie_path in the config?
If not, your cookies for one instance were being used with another
instance, with unpredictable results. Although from recent discussion
here on -dev, it looks like there might be a bug with cookie_path.
--nate
Yes I did, and it was different for both instances. I just checked.
L-A
> 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
>>>
>>>
>>>
>>>