Mickonis: I put the same number of columns in here though.

Walp: Http://pastie.org/10428175

Autman: Please only ignore me once

Howdeshell: I don’t get how an if does anything here that can returned unioned results

Swed: IF returns the second or third parameter depending on the value of the first param, nothing more or less

Finnemore: I don’t see how that helps for what I’m trying to do.

Keiter: Sadtaco: yes yes yes you did.

Sween: Http://pastie.org/10428194 I would think this would work. but it doesn’t. Doesn’t return a ton of results that it should.

Doyscher: Maybe left join but. dunno still would that do anything?

Hentrich: Is there really no way to take the selected results and select more based on those? If I could just select things where name IN and type IN.

Husbands: And LIMIT 1 is just going to return a single row, not a single row for each name field.

Giddins: I guess I just order and group by.

Pooyouma: Did that person just lead me on a wild goose chase or something

Mangiapane: Sadtaco: yes you’re right. needs a subquery on each one before joining them.

Kraasch: SELECT t1.name, t1.type, t1.json, t1.unixtime, t1.last_author FROM object_revisions AS t1 WHERE t1.unixtime 1438401600 GROUP BY t1.name, t1.type ORDER BY t1.unixtime DESC . ASC or DESC on the order by here gives me the same row each time, which is not the most recent that’s less than 1438401600

Ngyun: I’m a tricky situation, and need help/advise:

Tamimi: I run 2 servers, beta and production, each with own mysql db

Scheets: But a point has come when i’m required to ensure the code working in beta now works exactly same in production

Chancey: The prob is, part of the app’s structure relies on structures stored in the db

Mozier: And these, don’t have exact same ids for example in beta n production

Sardinha: Plus, production db contains some data we can’t just override

Thulin: So, what could be the best strategy for moving the essential changes from beta to production db?

Bosco: Sort of want to echo certain records from the beta db, into the production db, without overriding what’s there

Furnish: Danblack: Sorry, I have no idea about that manual entry.

Romanoski: Danblack: Sorry, I have no idea about that manual entry.

Goodenberger: Nemesisfixx: See http://dev.mysql.com/doc/refman/5.6/en/insert.html

Waffenschmidt: Danblack: ah, let me check that out

Brabson: Its a bit hard to say based on you descriptoin if that’s what you need. do the beta db ids need to got into production under a different id?

Kaloudis: Danblack: so is it posssible to insert into db A, by directly selecting from db B?

Munda: Or would i have to script this.

Euser: Danblack: i need to preserve the beta IDs in production

Greil: Insert ignore into dbA.tblA select . from dbB.tblX

Tuggles: It’s a flaw i have to leave with for now, because somehow, the code is ugly in some parts

Sherick: I’ve no idea what beta IDs mean or how your app log works.

Peak: DB ids are referenced in code

Hartjen: Well first see if there are beta ids that conflict with production

Fults: Nways, nice tip there.

Sesay: Nemesisfixx: SELECT a.* FROM a LEFT JOIN b ON a.id = b.id WHERE b.id IS NULL;

Mozga: And then change them so they don’t conflict in code and db at the same time.

Sam: How could this pseudocode look in real sql? SELECT id FROM t1 JOIN t2 ON t2.id=t1.id AND t2.x=t1.x IF THAT DOES NOT EXITS JOIN t2 ON t2.id=t1.id AND t2.x=NULL ORDER BY t2.sort

Trumball: No_gravity: SELECT a.* FROM a LEFT JOIN b ON a.id = b.id WHERE b.id IS NULL;

Lobban: That is something different

Pomerantz: No_gravity: sqlfiddle.com is an easy way to share your schema, your data, and the queries you’re testing. It saves us time and makes it more likely that you’ll get an answer! Make sure you set it to use MySQL.