But everyone involved wants MB to be able to do this.
djce
Then... we'll see?
ruaok
If MB can't then the CCCP is some serious issues.
djce
Presumably the branch can't go live if the answer is No.
ruaok
And they know that if we won't be allowed to do this, then MB will need to find another hosting solution.
So, I think the answer will be yes.
djce
OK. Let's not merge until we know for sure.
ruaok
Well, I was hoping to release it, but have a switch that disables the amazon features, but still lets the amazon asin/coverart urls be exposed via the web service.
But that seems pointless. So, lets hold off for now.
But, I should post something about it so people can test it.
I would like to release on the 15th.
djce
Sounds good..
assuming a yes just before?
or in semi-crippled mode?
ruaok
We release regardless. If the answer is no, we'll cripple it.
And start looking for a new hosting provider. :-(
But I think that is not likely to happen.
so, did we ever come to a conclusion on the 'serious weirdness mail' from whicken?
And when do we load the album release dates from whicken? I was planning on doing that for the release, but if the release is a ways off still we might want to do that before then...
djce digs out the mail
djce
I think we came to a conclusion.
Namely that there are still bugs relating to leading/trailing whitespace,
and still data in the DB with that problem,
so from time to time such errors will show up.
Not sure about the search index problem though;
certainly if the index is broke (for a given artist), then it won't "just fix itself"
not unless the artist name changes.
ruaok
so, maybe enter an RFE for yalaforge for a tailing whitespace cleanup?
djce
So what Wendell calls "serious weirdness" I might call "unfortunate bugs resulting in inconsistent data views".
yes, but it's not just a cleanup.
First, the server will have to stop accepting the bad data.
ruaok
input validation as well.
djce
Maybe something to seek out and repair index errors.
i.e. artistwords et al
sward_3 has quit
Knio-school
Knio-school is now known as Knio
ruaok
djce: got a favor to ask you...
djce
shoot
ruaok
can you whip up two queries for us?
First, what coverage of artist subscriptions do we have?
how many artists are subbed? and which artists are subbed more than others?
And how many albums have release types?
djce
ok, give me a few minutes
ruaok
super!
djce
types? as live, single, album, remix?
ruaok
yes
djce
ok
ok, second one first.
this isn't the simplest way, but it illustrates the point.
create or replace view album_attrs as select id, name, artist, gid, attributes[1] as modpending, attributes[2] as x, attributes[3] as y from album;
select x,y,count(*) from album_attrs group by x,y order by 1,2;
as you'll see from the results it's a bit untidy... sometimes we have (type), sometimes (status), sometimes (type,status) or sometimes (status,type).
and sometimes neither.
you can then count "albums" by, for example: select count(*) from album_attrs where 1 in (x,y);
or "where 2 in"... for singles,etc.
ruaok
sorry, I'm back.
djce
ok
ok, here's a better SQL query:
do the "create or replace view" above first...
then:
create or replace view album_attrs_2 as select *, case when x between 0 and 99 then x when y between 0 and 99 then y end as reltype, case when x between 100 and 199 then x when y between 100 and 199 then y end as relstatus from album_attrs ;
then you can:
select reltype, count(*) from album_attrs_2 group by reltype order by 2 desc;
select relstatus, count(*) from album_attrs_2 group by relstatus order by 2 desc;
ruaok
nice!
so I'm seeing that more than half of the albums have a release type.
Am I reading that right?
djce
I think so.
nulls = no data, so that seems right
ruaok
and most of the releases have a status. not nad.
bad, that is.
djce
ok, on to subscriptions.
on bender:
select a.id, a.name, t.t from artist a, (select artist, count(*) as t from moderator_subscribe_artist group by artist) as t where a.id=t.artist order by 3 desc;
(top subbed artists)
(well all in fact; but most-subbed first).
ruaok
meager. :-(
NIN is a the top. Go figger.
djce
in histogram form:
select t as subscribers, count(*) as num from (select artist, count(*) as t from moderator_subscribe_artist group by artist) as t group by t order by 1;
(this shows that 6666 artists have one subscriber, 1 artist has 11 etc)
ruaok
woah.
1 | 1386
5 | 10
6 | 8
7 | 5
that's on test.
djce
then the same on the other axis, by moderator:
select t as artists, count(*) as num from (select moderator, count(*) as t from moderator_subscribe_artist group by moderator) as t group by t order by 1;