[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [UDD] Fixing (most) email addresses in upload_history table

On 23/01/11 at 17:33 +0100, Andreas Tille wrote:
> On Sun, Jan 23, 2011 at 03:55:55PM +0100, Lucas Nussbaum wrote:
> > >    1. Reimporting the whole upload_history* tables with the new importer
> > >       script?
> > >       -> I do not like it really because of the import problem I have
> > >          faced on my side and I do not really understand the implications
> > >          this might have.  I would not know what to do in case something
> > >          might break more heavily and if you have no time to fix a possible
> > >          break this might be bad timing.
> > >          However, I don't think a delay of doing the reimport will really
> > >          harm (I'll plan to do all the stuff, even the query for what I
> > >          need the fixed e-mail addresses) on blends.debian.net where I
> > >          know that this is the only application and I can not break
> > >          anything else.
> > > 
> > >    2. Just copying the patches for the importer to put it in effect for
> > >       the files which are processed from now on.
> > >       -> That's fine.  I can perfectly do this.
> > > 
> > >    3. Implementing the issue I mentioned in my hint above?
> > >       -> Hmmm, I'm not really motivated to fix this minor issue seems not
> > >          be that harmful (regarding the number of data we can really fix)
> > 
> > I meant (1), or at least (2).
> Done (2).
> Remark: I have no permissions to `svn up` ob udd (but I noticed that the
> production system on udd has a diff to svn!)  I also have no permission
> to `mv new_code old_code` and always need to to a `rm old_code` first.
> It's manageable but not optimal.

I've just made sure that all files permissions and ownerships are now
I've also committed the few things that were modified but not committed.

> Regarding (1):  To circumvent a (potentially problematic) reimport of
> all upload_history tables I could use an SQL update statement based on
> the initial SQL code I used when I brought up this problem.  It
> would/should have the same effect as a complete reimport.  Should I go
> for this and if yes should I commit the according SQL code in SVN as
> documentation?

If UDD now imports the data correctly, you could just do the UPDATE to
fix the current data. It's probably not necessary to commit them.

> In any case I would regard it quite important if somebody would have a
> look into the "Duplicated Key when doing a complete reimport of
> upload_history" problem.  Should I file a bug report and if yes against
> what (pseudo-)package?

If it works after manually deleting all the tables, then I don't think
that it's such a grave problem.

- Lucas

Reply to: