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