[codeface] Re: Project name uniqueness database constraint
- From: Wolfgang Mauerer <wm@xxxxxxxxxxxxxxxx>
- To: codeface@xxxxxxxxxxxxx
- Date: Wed, 19 Nov 2014 18:56:32 +0100
Am 19/11/2014 14:24, schrieb Mitchell Joblin:
> Is anyone aware of why the project name has a uniqueness constraint in
> the database? The reason I ask is because it makes it challenging to
> analyze the same project with different analysis methods. For example,
> if you analyze project_A with analysis method "proximity" then change
> only the analysis method to "file", the analysis will fail because of
> the uniqueness constraint. The work around is augmenting the project
> name with the analysis method (or anything that makes it unique) before
> re-running the analysis using another option. This seems redundant since
> we anyway already have a column in the project table that specifies the
> analysis method.
>
> Strictly from the analysis side, I think there will be no problem with
> removing this constraint. I am wondering if the dashboard is somehow
> relying on this.
I don't expect any problems from the analysis side, but there could
be a few corner cases and rough edges here and there. Would need
to be tested.
From the front-end side, it is currently mandatory that there's
only one analysis method per project. A web front-end user should
not be concerned with the technical details of the analysis.
For instance, when one is interested in how stable communities of
a project are, it is irrelevant if they have been gained from a tag or
a2c analysis, as long as the chosen approach provides an accurate
representation of project reality.
It would be helpful to have multiple analyses for a project when
working on the actual methods. Providing these results in the frontend
would likely confuse most users, so we should keep the details
away from there, or make it only accessible for users who
know exactly what they are doing.
The easiest way to satisfy both requirements would, from the top
off my head, be to
- Allow for multiple analysis methods per project by extracting
analysisMethod/analysisTime into a separate table that can contain
multiple instances.
- Mark one method as default method
- Use a unique id per (name, method) tuple
- Change the web frontend to show results for the default method
unless a different analysis method is explicitly requested with
some to-be-implemented means.
This way, we can keep the front-end simple to use, while enabling
comparative research on different methods.
Best regards, Wolfgang
Other related posts:
