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<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
>>
>>
>>
>>
>> ___________________________________________________________
>> 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/