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=f2db41e... 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@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@bx.psu.edu

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=f2db41e... 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@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@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

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.

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@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=f2db41e...

...

...

...

...

...

> 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@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@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

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 Kustergreg@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=f2db41e...

...

...

...

>>> 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@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@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@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/

Ooops, this is very right, I totally forgot about that. It woud have become problematic at some point I guess. Thank you for pointing this out!

I changed it so the new database is associated with brand new appropriate directories. (and dropped and re-created the db again) But I keep getting the same error message with supposedly nonexistent histories.

Thanks again L-A

Le vendredi 15 avril 2011 à 13:47 +0200, Hans-Rudolf Hotz a écrit :

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 Kustergreg@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=f2db41e...

...

>>>>> 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@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@bx.psu.edu >> >> >> >> >> >> > >

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@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/

On 04/18/2011 11:28 AM, Louise-Amélie Schmitt wrote:

Hello again

I tried deleting the compiled templates like Sarah Diehl did for her user registration issue:

...

first thank you for your help. I tried reloading everything, cleared

the cache of my browser and tried it on a different computer whose browser never before was on the Galaxy website. All of this did not work. What worked in the end was deleting the compiled_templates directory.

But it didn't work either. I'm back to square one, with no option in sight. I keep getting the same error message when trying to add datasets.

Any idea?

well, do it the hard way and start from "square one":

- is galaxy working out of the box (fresh checkout, using SQLite)

- is galaxy working out of the box (using a non-root user called galaxy, using a fresh checkout downloaded and installed into the galaxy user home directory and use PostgreSQL)

+ is it still working when you change to "require_login = True"

+ is it still working when you change to "use_remote_user = True"

at which point does it stop working?

Hans

Cheers, L-A

Le vendredi 15 avril 2011 à 16:52 +0200, Louise-Amélie Schmitt a écrit :

...

Ooops, this is very right, I totally forgot about that. It woud have become problematic at some point I guess. Thank you for pointing this out!

I changed it so the new database is associated with brand new appropriate directories. (and dropped and re-created the db again) But I keep getting the same error message with supposedly nonexistent histories.

Thanks again L-A

Le vendredi 15 avril 2011 à 13:47 +0200, Hans-Rudolf Hotz a écrit :

...

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 Kustergreg@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=f2db41e... >>>>>>> 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@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@bx.psu.edu >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> Greg Von Kuster >> Galaxy Development Team >> greg@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@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/

---

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/

Ok, now it's the other install that doesn't work anymore.

Looks like a cuckoo's nest, they must be sharing something they shouldn't, first arrived first served.

But I really don't see what's going wrong: - They run from distinct galaxy copies - They use different databases - They use different file paths for their respective data - They don't use the same ports

The only things they share to my knowledge is the machines they run on, Apache and Python

If anyone has an idea on what is going wrong and is willing to share it, I'll be forever grateful!

Regards L-A

Louise-Amelie Schmitt wrote:

Hello, and sorry for the late reply

All the answers are yes, since it didn't stop working at all.

I fear transferring the data again now...

Hans-Rudolf Hotz wrote:

...

well, do it the hard way and start from "square one":

• is galaxy working out of the box (fresh checkout, using SQLite)

• is galaxy working out of the box (using a non-root user called galaxy, using a fresh checkout downloaded and installed into the galaxy user home directory and use PostgreSQL)

  • is it still working when you change to "require_login = True"

  • is it still working when you change to "use_remote_user = True"

at which point does it stop working?

Hans

...

Cheers, L-A

Le vendredi 15 avril 2011 à 16:52 +0200, Louise-Amélie Schmitt a écrit :

...

Ooops, this is very right, I totally forgot about that. It woud have become problematic at some point I guess. Thank you for pointing this out!

I changed it so the new database is associated with brand new appropriate directories. (and dropped and re-created the db again) But I keep getting the same error message with supposedly nonexistent histories.

Thanks again L-A

Le vendredi 15 avril 2011 à 13:47 +0200, Hans-Rudolf Hotz a écrit :

...

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 >>> Kustergreg@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=f2db41e... >>> >>>>>>>>> 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@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@bx.psu.edu >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> Greg Von Kuster >>>> Galaxy Development Team >>>> greg@bx.psu.edu >> >> Greg Von Kuster >> Galaxy Development Team >> greg@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/

---

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/

---

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/

On Thu, 2 Jun 2011 11:48:55 -0400, Nate Coraor nate@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@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=f2db41e...

...

...

...

...

...

>>> 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@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@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

Le 02/06/2011 21:23, Nate Coraor a écrit :

Louise-Amélie Schmitt wrote:

...

On Thu, 2 Jun 2011 11:48:55 -0400, Nate Coraornate@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 Kustergreg@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=f2db41e...

...

...

...

...

>>>>> 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@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@bx.psu.edu >> >> >> >> >> >> > Greg Von Kuster Galaxy Development Team greg@bx.psu.edu

Greg Von Kuster Galaxy Development Team greg@bx.psu.edu