[Qa-debsources] patch-tracker DB schema

[Stefano Zacchiroli]

On Thu, Jan 21, 2016 at 09:11:00PM +0100, Orestis Ioannou wrote:
> > I don't understand what you plan to store in the file deltas
> > JSON. Here too, an example (or a JSON schema) would help the
> > discussion.
> 
> 
> So the thing is that when providing the summary of a package we have:
> 
> - File delta
> - description
> 
> Taking https://sources.debian.net/patches/summary/gnubg/1.05.000-3/
> the idea is having a json object like (not with the name file_deltas
> am sorry that was wrong):
> 
> {
> 	description: "------"
> 	file-delta: {
> 		'eval.c': '10 6 + 4 - 0 !',
> 		'util.h': '3 3 + 0 - 0 !',
> 		summary: '2 files changed, 9 insertions(+), 4 deletions(-)'
> 	}
> 
> }

I see. So this is a parsed version of the diffstat, listing all affected
files and summarized changes --- by-file, and overall.

> Well pfff i am not sure if this is really needed. It is just to avoid
> parsing all the patches for these informations on the fly on each
> request. Its not that it is slow to do it on the fly. Do you think it
> is better not to do it? In this case i think this table is not needed
> at all.

On the one hand, we might have large patches, that might take a while to
parse. On the other hand there are easier ways to DoS Debsources than
fishing for large patches, so I'm not sure we should worry too much
about the performance angle.

The question is more what we can do with the extra information if we
store them in the DB. Note that if we store them as JSON(B) fields there
isn't much we can do with them; whereas if we model them relationally
more interesting opportunities might open up. But I don't think we have
an actual use case for this (yet).

So, until interesting use cases arise, I'm moderately against parsing
patches at update time.

> > Same comment as above: useful information, but I'm not sure yet it
> > should be in the packages table. How about adding a source package
> > table? Thinking of it, this table might be the same that contains both
> > the SHA256 (and possibly other checksums) and the patch format.
> 
> ack agreed, a separate table is better

Cool

> > I don't remember this specific use case. Am I reading you right, by
> > saying that what was desired here is a global diff w.r.t. upstream,
> > uniting all patches together? Frankly, I'm not sure it would be that
> > useful as a use case...
> 
> Ok good for me as well

Let's scrap that then.


Do not forget to send on list a full SQL proposal, as (at least I)
haven't seen it yet :-)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack at upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/qa-debsources/attachments/20160127/ed74862a/attachment.sig>