Mickonis: I put the same number of columns in here though.
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.