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
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.