On Jul 26, 2005, at 11:41 AM, Tobias Luetke wrote:
>> One thing that we need to add is a
>> requirement for the user to restart their fastcgi servers after
>> finishing the migrations; without doing that, the migration won't be
>> complete and random errors will occur.
>>
>
> I think we could traverse the ObjectSpace and call
> reset_column_information for all objects which respond to it. This
> might fix the issue.
That'll work for one fastcgi instance, but what about all of the
others? I don't think we have any way to communicate between them.
Scott
From mburnham1973 at gmail.com Tue Jul 26 14:52:06 2005
From: mburnham1973 at gmail.com (Mike Burnham)
Date: Tue Jul 26 14:46:28 2005
Subject: [typo] Upgade errors
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
To get past the user_id problem, I just deleted the user_id column from the
database and ran rake migrate.
I'm not sure what the repercussions are of this but I'm not scared! (that
and I backed up everything before going crazy)
On 7/26/05, Scott Laird <[EMAIL PROTECTED]> wrote:
>
>
> On Jul 26, 2005, at 11:41 AM, Tobias Luetke wrote:
>
> >> One thing that we need to add is a
> >> requirement for the user to restart their fastcgi servers after
> >> finishing the migrations; without doing that, the migration won't be
> >> complete and random errors will occur.
> >>
> >
> > I think we could traverse the ObjectSpace and call
> > reset_column_information for all objects which respond to it. This
> > might fix the issue.
>
> That'll work for one fastcgi instance, but what about all of the
> others? I don't think we have any way to communicate between them.
>
>
> Scott
> _______________________________________________
> Typo-list mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/typo-list
>
--
http://blog.closingbracket.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/typo-list/attachments/20050726/e30209a7/attachment.htm
From scott at sigkill.org Tue Jul 26 14:56:47 2005
From: scott at sigkill.org (Scott Laird)
Date: Tue Jul 26 14:51:15 2005
Subject: [typo] Upgade errors
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On Jul 26, 2005, at 11:49 AM, Scott Laird wrote:
>
> That'll work for one fastcgi instance, but what about all of the
> others? I don't think we have any way to communicate between them.
If we're willing to take the performance hit, we could add a
before_filter on ApplicationController that compares (select version
from schema_info) with @@schema_info; if they don't match then it
calls the schema reload code. With caching, the hit probably won't
be all that objectionable.
Scott
From robin-lists at robinbowes.com Tue Jul 26 15:31:36 2005
From: robin-lists at robinbowes.com (Robin Bowes)
Date: Tue Jul 26 15:25:52 2005
Subject: [typo] Upgade errors
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Scott Laird wrote:
>
> You're seeing a couple different bugs here. First, you have stale page
> cache entries that didn't get removed automatically by the upgrade. Do
> 'rm -rf public/index.html public/articles' and then you should be
> okay.
I did this and restarted httpd - that fixed it.
> The migrations *should* have fixed this for you, but clearly you
> had problems with them.
I did indeed. I hope my write up will help you fix them.
> I've seen a number of people with similar
> issues on the IRC channel; I think we're going to have to spend a bit
> of time testing the upgrade process to make sure that it's as
> trouble-free as possible.
Indeed. I was impressed when I saw the upgrade process having read about
it on the rails list. I was less than impressed when it failed! :)
> One thing that we need to add is a
> requirement for the user to restart their fastcgi servers after
> finishing the migrations; without doing that, the migration won't be
> complete and random errors will occur.
That's a toughy. Won't it require some sort of system admin
intervention? That requirement would limit the usefulness of typo in a
shared hosting environment.
>
> From where I'm sitting, this is the last really big thing between us
> and 2.5.
2.5? What version am I running?
R.
--
http://robinbowes.com
If a man speaks in a forest,
and his wife's not there,
is he still wrong?
From tobias.luetke at gmail.com Tue Jul 26 15:42:32 2005
From: tobias.luetke at gmail.com (Tobias Luetke)
Date: Tue Jul 26 15:37:20 2005
Subject: [typo] Upgade errors
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
> That'll work for one fastcgi instance, but what about all of the
> others? I don't think we have any way to communicate between them.
Doh, you are right. Well we can tell the user to restart the web
server in big and fat letters after a migration run.
--
Tobi
http://www.snowdevil.ca - Snowboards that don't suck
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog
