launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Thu, Jul 29, 2010 at 6:52 PM, Abel Deuring
<abel.deuring@xxxxxxxxxxxxx> wrote:
> Hi Stuart,
>
> I am currently working on
> https://bugs.edge.launchpad.net/malone/+bug/39674 (Attachments of
> private bugreports are public). This involves of course to set the
> attribute LFA.restricted to True for private bugs.
>
> My first idea was to simply set the restricted flag of all LFAs of
> BugAttachments of a bug in the method Bug.setPrivate().
>
> But a comment from Robert in
> https://code.edge.launchpad.net/~adeuring/launchpad/bug-39674-lfa-editable/+merge/29314
> let me think again if we should enforce the consistency of
> LFA.restricted and Bug.private on the database level.
>
> If we ensure that at least LFAs of BugAttachments are referenced exactly
> once (in a trigger for UPDATE and INSERT statements for all tables which
> reference LFAs, see my reply to Robert in the MP), we can add a trigger
> for the table Bug to ensure that you can set private=true only if
> LFA.restricted is true for all related LFAs, and we could add a trigger
> for LFA to ensure that you can set LFA.restricted=false only if this LFA
> is not referenced by the table bug or if the referencing row of Bug has
> private == false.
>
> Setting the LFA.restricted immediately in a trigger of the table Bug. is
> probably not a good idea:
> (1) IIRC, Robert and Graham recently chased a bug which was caused by an
> inconsistency between data in a cached Storm object and the "real" DB
> data which was changed by a trigger,
> (2) Once bug 39674 is fixed, we might also allow private attachments for
> public bugs -- this would make it less risky to add bug attachments
> containing for example core dumps or stack traces to bugs which don't
> need to be private. (I think there are also some bugs filed for such a
> feature)
>
> What do you think?

I think there is too much overhead involved in maintaining this
constraint and we should just keep this logic at the application level
rather than in the database.


-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/