1) I don't see why the modules need to depend on each other (with Python's dynamic typing)
2010-03-30 08924, 2010
luks
2) I don't think modules depending on each other is a big problem
2010-03-30 08955, 2010
yalaforge
re 1) even a "dynamic" dependency is still a dependency that violates your usual design principles
2010-03-30 08916, 2010
yalaforge
re 2) that's a matter of taste :)
2010-03-30 08921, 2010
luks
are we talking about the dumb model classes here?
2010-03-30 08928, 2010
yalaforge
yup
2010-03-30 08938, 2010
luks
where do you need a reference to the Release class in Artist?
2010-03-30 08939, 2010
yalaforge
when you request an artist from the web service and set the include parameter to include releases?
2010-03-30 08904, 2010
yalaforge
then you'll want to access the releases (or release groups) using Artist.releases
2010-03-30 08927, 2010
luks
and where do you need to call Release in the code?
2010-03-30 08950, 2010
luks
(I really don't see it, not just acting stupid :))
2010-03-30 08918, 2010
yalaforge
I don't have to reference the Release symbol from within the Artist class, that's right
2010-03-30 08923, 2010
yalaforge
hmm.
2010-03-30 08956, 2010
yalaforge
I think to me a logical dependency is just as bad as a real one. and you don't care, that's the difference :)
2010-03-30 08929, 2010
yalaforge
in practice there won't be much of a problem, that's where we agree
2010-03-30 08901, 2010
yalaforge is just looking for a decomposition that would work for strictly typed languages, too
2010-03-30 08926, 2010
yalaforge
after all, I want to create a reference model again. not just one for python
2010-03-30 08933, 2010
luks
in java you would simply import Artist in Release.java and Release in Artist.java
2010-03-30 08949, 2010
luks
in C++ you would need to use forward declarations, like libmb3 already does
2010-03-30 08903, 2010
yalaforge
yup. but like I said, there are no modules in java (and also none in c++)
2010-03-30 08949, 2010
yalaforge
in java I'd just throw all model classes into one package and that's it
2010-03-30 08908, 2010
yalaforge
no need to import anything because it's all the same package
2010-03-30 08917, 2010
luks
right
2010-03-30 08925, 2010
luks
but the classes still depend on each other
2010-03-30 08932, 2010
luks
I honestly don't see the difference :)
2010-03-30 08958, 2010
yalaforge
if I did cross package boundaries with my imports then you usual architectural metrics reports would detect that
2010-03-30 08944, 2010
yalaforge
well, what's a package in java is more like a module in python
2010-03-30 08956, 2010
yalaforge
(and python packages are something else entirely)
2010-03-30 08926, 2010
yalaforge
that's why pymb2 threw all model classes into one module (1500 LoC, *shudder*)
2010-03-30 08934, 2010
yalaforge
see what I mean?
2010-03-30 08939, 2010
luks
what about importing all the subpackages into musicbrainz2.models and leave that as an implementation detail
2010-03-30 08900, 2010
yalaforge
interesting idea
2010-03-30 08921, 2010
luks
the individual subpackages would work with models, not the subpackages
2010-03-30 08908, 2010
yalaforge
hmm, then you'd have bidirectional dependencies between __init__.py and the modules, right?
2010-03-30 08916, 2010
luks
yes
2010-03-30 08924, 2010
luks
but that's hidden :)
2010-03-30 08928, 2010
yalaforge
:)
2010-03-30 08915, 2010
yalaforge
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
2010-03-30 08940, 2010
ijabz joined the channel
2010-03-30 08942, 2010
yalaforge
so even if we have cycles, we don't have them between packages
2010-03-30 08914, 2010
yalaforge
and that's something really important, IMHO. I guess I can live with a few imperfections on module level
2010-03-30 08953, 2010
yalaforge will ponder about this some more
2010-03-30 08956, 2010
yalaforge
thanks luks!
2010-03-30 08924, 2010
luks
it's basically the same as the java idea
2010-03-30 08952, 2010
yalaforge
in a way, yes
2010-03-30 08930, 2010
aCiD2
Hrm, that whole 10-11am thing didn't happen
2010-03-30 08942, 2010
warp
:)
2010-03-30 08914, 2010
warp is doing something with revenue taxes
2010-03-30 08922, 2010
aCiD2
that sounds like heaps of fun
2010-03-30 08929, 2010
warp
in fact it is
2010-03-30 08950, 2010
warp
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).
2010-03-30 08908, 2010
alastairp joined the channel
2010-03-30 08913, 2010
philip6137 joined the channel
2010-03-30 08903, 2010
Leftmost
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.
2010-03-30 08923, 2010
luks
the current NGS version is very simplified compared to the live version
2010-03-30 08909, 2010
luks
oh
2010-03-30 08914, 2010
luks
subscriptions
2010-03-30 08954, 2010
luks
that's almost identical to the live version
2010-03-30 08915, 2010
luks
editor_subscribe_artist
2010-03-30 08932, 2010
luks
or editor_subscribe_label, editor_subscribe_editor
2010-03-30 08904, 2010
luks
they link to the editor and then the subscribed entity
ah, I see the first few proposals have been submitted, great!
2010-03-30 08930, 2010
warp
aCiD2: anyway, what can I do regarding edit migration?
2010-03-30 08924, 2010
aCiD2
warp: read the document!
2010-03-30 08935, 2010
aCiD2
or if you have, we can get talking
2010-03-30 08957, 2010
warp
I'm reading it now (at 1.3).
2010-03-30 08910, 2010
warp
I assume X under Read-only means that edit type is read-only?
2010-03-30 08934, 2010
aCiD2
yea
2010-03-30 08901, 2010
warp
aCiD2: so, what now? :)
2010-03-30 08910, 2010
aCiD2
If you want to jump in, MOD_REMOVE_TRMID might be any easy one
2010-03-30 08905, 2010
aCiD2
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"
2010-03-30 08916, 2010
aCiD2
Then try and create a Dict[] format 'data' in the edit type
2010-03-30 08902, 2010
aCiD2
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)
2010-03-30 08907, 2010
aCiD2
and keep doing that until it stops erroring
2010-03-30 08921, 2010
warp
can I do this on master, or should I get a fancy edit-migration branch from you?
2010-03-30 08922, 2010
aCiD2
Then, I'll go back in and write related_entities, foreign_keys and build_display_data
2010-03-30 08930, 2010
aCiD2
You should do this off this commit:
2010-03-30 08944, 2010
aCiD2
a4c9d8603010f4997ed5b50fe16f400cb97443cc
2010-03-30 08903, 2010
aCiD2
so you might want to do: "git checkout -b read-only-edit-types a4c9d86"
2010-03-30 08939, 2010
aCiD2
Then "git checkout -b blah read-only-edit-types"
2010-03-30 08938, 2010
aCiD2
and it seems that REMOVE_TRMID got purged when we dropped them... so... maybe MOD_EDIT_TRACKTIME?
yea, they all are probably - but you'll have to check them out one by one, as each one has its own branch atm
2010-03-30 08904, 2010
warp
there's five files in that directory now, but those aren't edit types I guess.
2010-03-30 08915, 2010
aCiD2
one of them is
2010-03-30 08921, 2010
warp
EditReleaseName
2010-03-30 08924, 2010
aCiD2
yep
2010-03-30 08926, 2010
warp
ok
2010-03-30 08944, 2010
djce
I have a couple of quick q's about how mb_server runs under fcgi...
2010-03-30 08914, 2010
djce
First q: how horrible would it be if static resources weren't all directly under /static/
2010-03-30 08923, 2010
djce
say, under /static/$someinteger instead.
2010-03-30 08924, 2010
djce
?
2010-03-30 08958, 2010
djce
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)?
2010-03-30 08902, 2010
anthonynonso joined the channel
2010-03-30 08910, 2010
djce
I think I'm out of questions for now :-)
2010-03-30 08929, 2010
aCiD2
djce: will $someinteger change?
2010-03-30 08935, 2010
djce
at release time.
2010-03-30 08907, 2010
aCiD2
hrm, probably doable...
2010-03-30 08915, 2010
djce
With regards to static things actually not being static (i.e. at release, they might change), you can do one of two things:
2010-03-30 08933, 2010
djce
(a) ignore it. Put up with the fact that clients might use stale assets.
2010-03-30 08905, 2010
djce
(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.
2010-03-30 08914, 2010
djce
(sorry, s/two/three/)
2010-03-30 08934, 2010
djce
(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.
2010-03-30 08946, 2010
anthonynonso
hi all, i'm new here. looking to apply for GSoC
2010-03-30 08906, 2010
djce
I see some code along the lines of 'if href=="/static/..."' though.
2010-03-30 08932, 2010
warp
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.
