589786 - [dashboard] Create abstract models for Projects and Versions in Life

Status: RESOLVED WONTFIX

(Mozilla Localizations :: Infrastructure, defect)

Description

[Staś Małolepszy :stas]

Let's get this discussion started in bugzilla.

I'll attach a WIP patch today to gather early feedback.

Comment 1

[Staś Małolepszy :stas]

Attachment: WIP patch 1

Here's a WIP patch. It's more of a conversation starter than actual implementation. It adds 3 models to Life, and doesn't remove anything from Shipping. I don't want to go into the dependency hell of removing Shipping models before we agree that that is indeed what we want :)

The patch adds Project, Version and Milestone. It's largely based on the models from Shipping, with some minor method refactoring. 

My idea would be to remove Application, AppVersion and Milestone from Shipping and use Project, Version and Milestone from Life across all dashboard apps (that's homepage, shipping, todo... others?). Note that the change Application->Project is deliberate--I assume that 'projects' will also encompass websites and other one-off things we localize (surveys, PR guides etc).

(shipping.Milestone might need to stay around and maybe inherit from life.Milestone, not sure yet.)

Thoughts?

Comment 2

[Axel Hecht [:Pike]]

Comment on attachment 468406 [details] [diff] [review]
WIP patch 1

There are a few things I don't like here:

Firstly, the life app was originally designed to be something that could be run on hg.m.o. That's probably never going to happen, but I'd really like to not see that concept die. "life" as a name might be misleading there. On a meta argument, one could argue that milestones and versions etc are not as real-life as changesets, but that's overdoing it.

A similar argument holds for mbdb.

Conceptually, I'd expect common data for projects to be in the homepage app, as that's the app that is bringing the different apps in l10n_site together.

On the models, shipping.Milestone is going to dramatically change, that model didn't prove to be successful. I'm not sure if we need the three-level hierarchy for the abstract projects just because they seem to work in shipping, at least to some extent.

Right now, I'm thinking about ÜberProject to just be a GenericRelation to some other apps models, with common infrastructure to get to a details page, and possibly details.

Anyway, there seem to be some fundamental differences in thought leaking through here, I think we should get on a conf call and hash some of those out.

Comment 3

[Staś Małolepszy :stas]

Thanks Pike. It's helpful to see things from your POV. 

(In reply to comment #2)
> Firstly, the life app was originally designed to be something that could be run
> on hg.m.o. That's probably never going to happen, but I'd really like to not
> see that concept die. "life" as a name might be misleading there. On a meta
> argument, one could argue that milestones and versions etc are not as real-life
> as changesets, but that's overdoing it.

That's new to me. In that case, I'd expect the life app to be called hg-api-bindings app or something like this :)

And I'd still see a need for a proper "life" app.

> Conceptually, I'd expect common data for projects to be in the homepage app, as
> that's the app that is bringing the different apps in l10n_site together.

I'm not a huge fan of that idea, but this could work. I somehow tend to think about the homepage app as 'the app that shouldn't be.' Or at least, 'no models, please.'

> On the models, shipping.Milestone is going to dramatically change, that model
> didn't prove to be successful. I'm not sure if we need the three-level
> hierarchy for the abstract projects just because they seem to work in shipping,
> at least to some extent.

I think there's a significant difference in versions (which people think about) and milestones (which the backend operates on). I'd definitely recommend to keep both.

> 
> Right now, I'm thinking about ÜberProject to just be a GenericRelation to some
> other apps models, with common infrastructure to get to a details page, and
> possibly details.

That's a cool idea I'd be game for. 

> Anyway, there seem to be some fundamental differences in thought leaking
> through here, I think we should get on a conf call and hash some of those out.

Sure, I'll send an invite.

Thanks Pike!

Comment 4

[Staś Małolepszy :stas]

(In reply to comment #3)
> > Right now, I'm thinking about ÜberProject to just be a GenericRelation to some
> > other apps models, with common infrastructure to get to a details page, and
> > possibly details.

I was thinking about this in more detail as I was making progress on the todo app, and here's my thoughts:

 * I generally don't think we need one-to-many relations here.

 * Consequently, I'm not sure we need a generic relation in homepage to link projects in shipping, webby and todo. 

 * Instead, we could amend shipping.models.AppVersion to add a one-to-one relation to homepage.models.Project, or even directly to todo.models.Project. Not sure if there's a way in this scenario to link shipping.models.AppVersion with webby.models.Project.
 
 * We could also keep these relations in todo, using OneToOneField:

# todo.models.Project
class Project(models.Model):
    shipping = models.OneToOneField(shipping.models.AppVersion, related_name="todo")
    webby = models.OneToOneField(webby.models.Project, related_name="todo")

This would allow to do neat transitions like so:
fx40 = AppVersion.objects.get(code="fx4.0")
fx40.todo.open_tasks()

You could also, in theory, do something like this:
fx40 = AppVersion.objects.get(code="fx4.0")
fx40.todo.webby.main_lang_status()

 * The above solution, however, hardcodes shipping and webby into the todo app. A cleaner way would be to put these one-to-one relations in homepage:

# homepage.models.Project
class Project(models.Model):
    shipping = models.OneToOneField(shipping.models.AppVersion, related_name="home")
    webby = models.OneToOneField(webby.models.Project, related_name="home")
    todo = models.OneToOneField(todo.models.Project, related_name="home")

It's still fairly easy and clean to move between models:
fx40 = AppVersion.objects.get(code="fx4.0")
fx40.home.todo.open_tasks()
fx40.home.webby.main_lang_status()

Opinions?

Comment 5

[Staś Małolepszy :stas]

Comment on attachment 468406 [details] [diff] [review]
WIP patch 1

Marking the WIP patch 1 as obsolete.

Comment 6

[Axel Hecht [:Pike]]

That approach doesn't seem to work out for project apps that are not shipping and want to use todo, does it? I'd expect the OneToOne to both to actually be in shipping.models.AppVersion.

I'm seeing an opportunity to get icons and description blurb factored into homepage.models.Project, fwiw.

Also, IMHO,

fx40 = AppVersion.objects.get(code="fx4.0")
fx40.todo.webby.main_lang_status()

may very well be pretty slow, as each dot get's a full obj query afaik, one after one. Probably better to directly do a webProject.get(appversion__code='fx4.0')....

(Whether that should be a method, tbd)

Comment 7

[Staś Małolepszy :stas]

(In reply to comment #6)
> That approach doesn't seem to work out for project apps that are not shipping
> and want to use todo, does it? I'd expect the OneToOne to both to actually be
> in shipping.models.AppVersion.

Why not? I gave the example of webby above. I forgot to make those one-to-one's optional, so the corrected model would look like this:

# homepage.models.Project
class Project(models.Model):
    shipping = models.OneToOneField(shipping.models.AppVersion, blank=True, null=True, related_name="home")
    webby = models.OneToOneField(webby.models.Project, blank=True, null=True, related_name="home")
    otherprojectapp = models.OneToOneField(otherprojectapp.models.Project, blank=True, null=True, related_name="home")
    todo = models.OneToOneField(todo.models.Project, related_name="home")

I wanted to keep the OneToOne's away from project apps (shipping, webby) and in homepage, but I guess I'm fine either way. My initial code just added the OneToOne to AppVersion, too, in fact.

> I'm seeing an opportunity to get icons and description blurb factored into
> homepage.models.Project, fwiw.

That could work. Would you mind drafting a spec of homepage.models.Project to include this and the OneToOne relations you're proposing?

Comment 8

[Staś Małolepszy :stas]

I didn't want this to block me, so I created todo.models.project for now: http://bitbucket.org/stasm/todo/src/tip/models/project.py

Comment 9

[Axel Hecht [:Pike]]

Well, we could keep the app-interactions out of, say, shipping, but then the project model in homepage should really be specific to shipping and then add app models. Sounds like http://docs.djangoproject.com/en/dev/topics/db/models/#multi-table-inheritance might be that?

That would also imply that much of the view code for the projects would then live in homepage and only pull snippets or data helpers from the apps, right?

Comment 10

[Axel Hecht [:Pike]]

Stas, given our recent discussions, is this WONTFIX?

Comment 11

[Staś Małolepszy :stas]

Yes. 

I use todo.models.Project instead (https://github.com/stasm/todo/blob/master/models/project.py).

Applications that wish to use todo need to create a link between their representations of projects and todo.models.Project, like so:

from todo.models import Project as TodoProject
class YourProject(models.Model):
    ...
    todo = models.OneToOneField(TodoProject, related_name="yourproject")

(cf. https://github.com/stasm/todo/blob/master/README.rst)

This still leaves rooms for a homepage.models.Project if we need it.