#musicbrainz-devel

1) I don't see why the modules need to depend on each other (with Python's dynamic typing)

2) I don't think modules depending on each other is a big problem

re 1) even a "dynamic" dependency is still a dependency that violates your usual design principles

re 2) that's a matter of taste :)

are we talking about the dumb model classes here?

yup

where do you need a reference to the Release class in Artist?

when you request an artist from the web service and set the include parameter to include releases?

then you'll want to access the releases (or release groups) using Artist.releases

and where do you need to call Release in the code?

(I really don't see it, not just acting stupid :))

I don't have to reference the Release symbol from within the Artist class, that's right

hmm.

I think to me a logical dependency is just as bad as a real one. and you don't care, that's the difference :)

in practice there won't be much of a problem, that's where we agree

after all, I want to create a reference model again. not just one for python

in java you would simply import Artist in Release.java and Release in Artist.java

in C++ you would need to use forward declarations, like libmb3 already does

yup. but like I said, there are no modules in java (and also none in c++)

in java I'd just throw all model classes into one package and that's it

no need to import anything because it's all the same package

right

but the classes still depend on each other

I honestly don't see the difference :)

if I did cross package boundaries with my imports then you usual architectural metrics reports would detect that

well, what's a package in java is more like a module in python

(and python packages are something else entirely)

that's why pymb2 threw all model classes into one module (1500 LoC, *shudder*)

see what I mean?

what about importing all the subpackages into musicbrainz2.models and leave that as an implementation detail

interesting idea

the individual subpackages would work with models, not the subpackages

hmm, then you'd have bidirectional dependencies between __init__.py and the modules, right?

yes

but that's hidden :)

:)

at least one thing I'm sure of: users of the API should import the package and where the individual classes come from (which modules) shouldn't matter to them

so even if we have cycles, we don't have them between packages

and that's something really important, IMHO. I guess I can live with a few imperfections on module level

thanks luks!

it's basically the same as the java idea

in a way, yes

Hrm, that whole 10-11am thing didn't happen

:)

that sounds like heaps of fun

in fact it is

because MetaBrainz isn't paying sales tax over the invoices I send there, but I do get sales tax back from the stuff I'm buying for my company here. (If I understand things correctly).

I'm looking at the schema for NGS and I'm not seeing how subscriptions are stored. I'm assuming I should be including that in my proposal if it's something I'd work on given time.

the current NGS version is very simplified compared to the live version

oh

subscriptions

that's almost identical to the live version

editor_subscribe_artist

or editor_subscribe_label, editor_subscribe_editor

they link to the editor and then the subscribed entity

Very simple tables, I assume?

the two important columns are editor and artist

Okay, thank you.

Some strong applications for GSoC this year!

there is quite some activity

ah, I see the first few proposals have been submitted, great!

aCiD2: anyway, what can I do regarding edit migration?

warp: read the document!

or if you have, we can get talking

I'm reading it now (at 1.3).

I assume X under Read-only means that edit type is read-only?

yea

aCiD2: so, what now? :)

If you want to jump in, MOD_REMOVE_TRMID might be any easy one

Here's the way I've been developing. Look up the old type of the edit in ModDefs.pm (svn checkout) and then do a "SELECT * FROM public.moderation_closed WHERE type = <type> LIMIT 10"

Then try and create a Dict[] format 'data' in the edit type

Then write sub upgrade. Next, I run ./admin/MigrateEdits (I usually edit MusicBrainz::Script::MigrateEdits->run to only get edits with type = <type>, editing the SELECT)

and keep doing that until it stops erroring

can I do this on master, or should I get a fancy edit-migration branch from you?

Then, I'll go back in and write related_entities, foreign_keys and build_display_data

You should do this off this commit:

a4c9d8603010f4997ed5b50fe16f400cb97443cc

so you might want to do: "git checkout -b read-only-edit-types a4c9d86"

Then "git checkout -b blah read-only-edit-types"

and it seems that REMOVE_TRMID got purged when we dropped them... so... maybe MOD_EDIT_TRACKTIME?

or perhaps MOD_CHANGE_ARTIST_QUALITY

you need to fetch from acid2 first

ok, that worked.

warp: here's a template too:

is anything in Edit/Historic a good example?

yea, they all are probably - but you'll have to check them out one by one, as each one has its own branch atm

there's five files in that directory now, but those aren't edit types I guess.

one of them is

EditReleaseName

yep

ok

I have a couple of quick q's about how mb_server runs under fcgi...

First q: how horrible would it be if static resources weren't all directly under /static/

say, under /static/$someinteger instead.

?

Next q: how can one restart / reload the fcgi processes (e.g. to get them to re-run any "at first start" code), and how quickly can that happen (e.g. would it interrupt service)?

I think I'm out of questions for now :-)

djce: will $someinteger change?

at release time.

hrm, probably doable...

With regards to static things actually not being static (i.e. at release, they might change), you can do one of two things:

(a) ignore it. Put up with the fact that clients might use stale assets.

(b) Don't change things, e.g. if you want a different foo.js then call it foo2.js, and one release later you can delete foo.js.

(sorry, s/two/three/)

(c) Always include a release ID in the URL, so that at each release, the URLs used are all new, thus not cached by clients.

hi all, i'm new here. looking to apply for GSoC

I see some code along the lines of 'if href=="/static/..."' though.

djce: if it's just to prevent stale data being served, we can just append ?t=$someinteger, the actual resources don't have to be served any differently.

Like http://jira.musicbrainz.org/browse/MBH-7 you mean :-D

OK. So, just for stylesheets, or for all "static" assets?

djce: it's not quite the same as MBH-7

warp means that instead of changing the file name, we just change how we request the file (by appending query parameters on)

Yes...

which is what MBH-7 is about.

UpdateStyleSheetLinks is about changing file names

I thought, anyway

i've never programmed python, but i'm pretty good with ruby

Yes, but the two things are related, aren't they.

djce: they are.

anthonynonso: best to ask in #musicbrainz, we're a little busy atm :)

aCid2: thanks, i'll do that!

MBH-7 is *exactly* what this is about. So, if we're happy to possibly serve stale (say) images, but we can force fresh css, then that's fine:

all we need is for UpdateStyleSheetLinks to exist in NGS, then for layout.tt to request main.css?t=$( mtime of main.css )

aCiD2: as long as we are using c.uri_for everywhere, we should be able to extend it to include a release id, right?

where the mtime can either be checked for every request, or if you prefer, at fcgi startup time.

warp: sort of.... except for the cases where it's referred to in static assets.

ah, right.. the stuff in /static will have relative links to other stuff in /static. so what I just said is nonsense, or atleast not good enough.

warp: I think so

i.e. static referring to static.

djce: I'm not sure we have that very often though

e.g. root/static/scripts/switch.js: if ($(this).attr("src") == "/static/images/release_editor/edit-off.gif") {

root/static/scripts/switch.js: src: "/static/images/release_editor/edit-off.gif",

ah, hrm

ofcourse, we can easily create a c.uri_for equivalent for javascript.

not so easy for .css