#musicbrainz-devel

we don't use RAWDATA anymore, and haven't for ages

git rev-parse HEAD

paste the output of that

8a9043141811e94314c78f522530fd68ff3f7d28

that's from July 2011

you need to: git fetch origin && git checkout v-2012-01-12-schema-change

but I don't think your REPLICATION_TYPE is RT_SLAVE either

which the blog post instructs

it is RT_SLAVE..not sure what u mean..

i had done those commands before but had some issues..let me do it again..

well it only runs "RunExport" if you're RT_MASTER, but if you're sure DBDefs is correct, then don't worry :)

oh u are correct..when i switched to default for now..it set to standalone..let me correct that..

is this good now..git rev-parse HEAD ee7b694698475b35b52e18486963830f62b85ed9

./upgrade.sh Mon Jan 16 08:59:25 PST 2012 : Adding CAA flag to release_meta BEGIN CREATE TYPE ALTER TABLE COMMIT Mon Jan 16 08:59:30 PST 2012 : Adding support for finding edits by relationship type BEGIN ERROR: language "plperlu" does not exist HINT: Use CREATE LANGUAGE to load the language into the database. ROLLBACK Mon Jan 16 08:59:30 PST 2012 : Adding new edit indexes BEGIN ERROR: function extract_path_value(text, u

let me do this step again..Install any necessary perl modules by running perl ./Makefile.PL and sudo make installdeps

sorry, checkout v-2012-01-12-schema-change-2

git checkout v-2012-01-12-schema-change-2 Previous HEAD position was ee7b694... Add a call to CREATE LANGUAGE in the CreatePLPerl init script, as this is important HEAD is now at eb89c2b... Another fix for LoadReplicationChanges and removed plperl updates for slaves in upgrade.sh

is that ok?

that's fine

upgrade.sh should not try and do that plperlu stuff now

should i do step 5 again before upgrade.sh

but I imagine it'll fail because part of the upgrade went through

nah

k

./upgrade.sh Mon Jan 16 09:06:07 PST 2012 : Adding CAA flag to release_meta BEGIN ERROR: type "cover_art_presence" already exists ERROR: current transaction is aborted, commands ignored until end of transaction block ROLLBACK Mon Jan 16 09:06:07 PST 2012 : Going to schema sequence 14 UPDATE 1 Mon Jan 16 09:06:07 PST 2012 : UPDATE THE DB_SCHEMA_SEQUENCE IN DBDefs.pm TO 14 ! Mon Jan 16 09:06:07 PST 2012 : Done

is that good?

yes, I think you're done now

update the sequence to 14 in DBDefs

thanks..i need to try on the other VM host tomorrow..which is our actual master VM host..so actually the way we setup is ..our MB DBs are external and it's setup as Master DB and Replicate slave..so any changes done to Master DB would apply to our Slave DB..

resosarevok, hi

reosarevok: hi

ijabz: I set search server and mmd-schema up on ci btw, so nothing to do there :)

ocharles thumbs up

an xml schema change commit to mmd-schema will now retest both the search server and musicbrainz-server

ijabz has changed the topic to: Agenda: reviews, default to advanced search? (reosarevok), meta description for google (kepstin), Cover Art Proposal (ijabz)

thats usefu;l

ijabz, hi

sounds fun

So if I take a while to reply, that's it

I dint know if you wanted a pre chat about your advanced search agenda topic

Can't hurt I guess

I am partially wondering why we have a non-advanced search at all, partially hoping I can at least get a preference for the search in the upper corner of MB to be advanced

+1

As I've never seen a case in which I'd need to use the non-advanced search

And what do you consider the difference to be between advanced and not advanced

As in, with advanced=1 activated

Yeah, sure but I'm interested to know what you think the difference is if you select/deselect that option

I'd usually like to do searches involving advanced syntax

That is half of it.

http://musicbrainz.org/search?query=planets+AND... vs. http://musicbrainz.org/search?query=planets+AND...

warp: what calls /ws/js/freedb?

The second result is much more useful, but getting to it involves either doing a search I don't need before

Or going to the search page to search there

The trouble is users who do not understand the lucene search syntax (which is most users) can end up creating invalid queries because they do not know that they have to escape some characters

Then I guess a preference would make sense

I know what our devs think of preferences, but still

imo, it's not a case of advanced search here

but http://musicbrainz.org/search?query=planets+hol... should be the same as your advanced search

Why?

because that's much more intuitive

if my dad wanted to find a specific release, he might try

But that list also includes stuff that has both words on the title

"Pink floyd - dark side of the moon"

Which makes sense

reosarevok: Hmm, one of those searches is for release group…

he doesn't want to know he has to type artist:"Pink Floyd" -- that'll confuse the hell out of him

The other half, is that we can massage the query entered by the user when not doing advanced search, and I want to do more of that

hawke_, ooops, true

Still http://musicbrainz.org/search?query=planets+AND...

ijabz: that sounds like the better approach

That would also make sense

Doesn't help my ability to do useful searches from there, though :p

So we could change the default search fields or modify the query that is entered when you do basic search

pasting "FOOREC123" should search for catalog numbers

that should just work

We already do this for artist search so that it weights searches on artist, alias and sort name fields and weights pahrases over single matches

I’m still annoyed that the results are so completely different though, between basic and advanced.

it would seem like a non-advanced search should just search all indexes, and take whatever has the best score over all indexes

(as far as scoring)

ocharles: I've wanted that for years :/

ocharles: +1

either that, or allowing google to index mb.org so I could just use google search instead ;)

kepstin-netbook: That sounds like admitting failure. ;-)

actually hawk Ive decided to do implement some of your fuzzy matching ideas in the basic search http://tickets.musicbrainz.org/browse/SEARCH-167

ijabz: Thanks

But that doesn't mean you'll get the same results in basic and advanced, there would be no need for both if that was the case

ijabz: No, that’s fine. I just think that regular/basic search should give equally useful results for both

ocharles: hm, perhaps the freedb search in the "Add Disc" dialog of the relaese editor?

“aaron lebedeef” being the example there of course

ocharles:I think that should be a different option to allow search all indexes, and I did some work on that and opened a ticket on you to implement the guy bit

warp: nah, it's something that gives it a category and freedb id

s/guy/gui

ijabz: that was for all indexes and all types

Ok

I mean a smaller change which is all indexes for a certain type

Then

ijabz: at least, I thought you were looking at unified search, which is something a bit different

reosarevok has changed the topic to: Agenda: reviews, preference for advanced search? (reosarevok), meta description for google (kepstin), Cover Art Proposal (ijabz)

thresh: 3 boxes are there... Consecutives IPs

Because I get annoyed when I search for a release or discos and I get artists and stuff as well

ijabz: I don’t expect the same result, I just don’t expect the stuff I’m looking for which seems obviously correct to be buried at the end of the list

ijabz: IMO that (type-specific search) should be a feature of advanced search

ocharles:yes i was, I don't understand the difference with 'non-advanced search should just search all indexes, and take whatever has the best score over all indexes' and that

ijabz: An artist search (non-advanced) should return only artist results, but it should search over all "artisty" indexes

so...

artist name, sort name, comment, aliases

ocharles: yes.

ijabz: ocharles' proposal will still require that you pick a type to search, e.g. "release" - it just means that you could enter "pink floyd CAT-###" and find a release.

hawk, IMO the point of the basic search is that if Im searching for an artist I can just enter an artist in the search field and it will find me the best matches in the usual case, I don't want it to return me releases or release-groups

and a release search should search all "releasey" indexes - release title, comment, artist credits, etc

ocharles: the add disc dialog does a search on /ws/js/freedb?q=ALBUMTITLE&artist=ARTIST etc..

warp: oh, but the action says Args(2)

ocharles: if a search result is expanded it calls e.g. http://beta.musicbrainz.org/ws/js/freedb/blues/...

ah

thanks!

Whereas the advanced search allows me to search the artist index based on any criteria I choose, depending on what Im trying to achieve

advanced search is fine how it is, imo

ocharles:basic search does do that, but maybe needs to add a few more fields to search on

ok, sounds like it just needs more tuning then

Actually, you know currently you have some code on the musicbrainz server (I provided the regexp) that rewrites the artist query it sends to the search server, this query rewrite should be done on the search server

+1

I was going to say that

:)

Then I can do it more efficiently and much more easily improve the results returned by basic search

it's also not musicbrainz-server's job

Great, well I will add an extra parameter such as 'basic=true' and then you can just pas me the user entered value as is, and I wil deal with it

?advanced=1 would match better I think

meaning ?

meaning "this is an advanced search"

rather than being explicit about basic searches, i'd rather be explicit about advanced searches

because if our search is doing its job, advanced search should be the exception :)

But advanced is the default, i.e when using the web service it uses advanced

though I would like to add the option to use basic version from the web service as well

that feels inconsistent

but I can just pass advanced=1 from web service queries to the search server

thresh: 88.190.34.17|18|19

There is certainly a problem with the name, but what do you mean inconsistent

it's inconsistent that the default search on the website is basic, and advanced in the web service

but that's tangential to this discussion :)