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