#mysql
03 October 2007
Total 31 pages. You are browsing page 5/31.
First :: Prev :: [...] [3] [4] [5] [6] [7] [...] :: Next :: Last
03:24 <****> arjenAU: mysqldump isn't outputting my table spaces and log files
03:24 <****> hopefully that makese sense
03:24 <****> Simetrical: if someone pushes you out of the way because otherwise a large truck will run over you, is that agression or helpful?
03:25 <****> arjenAU: is there something specific that i have to do in order to get the table spaces and log files?
03:25 <****> arjenAU, ALTER TABLE *table* ADD FULLTEXT(column1, column2) right?
03:25 <****> rawake: nor should it.
03:25 <****> arjenAU: then why did you say it would? snadaskjdnaskjdnasjkd
03:25 <****> rawake: there's no data in log files as such, except as part of somehting else. like with innodb, but then you will get the data out as part of the whole.
03:25 <****> arjenAU, I don't view it as important, though. What's wrong if you want to reserve the first 1000 numbers for internal use with manually-inserted ID's, say, and start other ID's at 1001, and use those to discriminate between the two? Just for example.
03:26 <****> Simetrical: that's fine. but people here also ask about resetting and renumbering auto-incs. how do you feel about that?
03:26 <****> arjenAU: well what about the create statemetns for my table spaces and log files along with the adding table spaces to tables
03:27 <****> arjenAU, reusing them is normally pointless but not necessarily harmful. Modifying the AUTOINCREMENT value manually, too, could be done for some reasonable purpose.
03:29 <****> arjenAU, I agree that whatever information you hope to embed using such techniques might be more usefully stored as its own column, yes. But it's hardly a major thing. I wouldn't assume that anyone who cared about AUTOINCREMENT was making a mistake until I saw the specific application.
03:29 <****> rawake: mysqldump in 5.1 should do that. if it does not, it's a bug.make sure you have a recent mysqldump that comes with 5.1
03:30 <****> Simetrical: statistically, let's say 70% of people asking this type of question here are really doing the wrong thing.
03:30 <****> arjenAU, more than 70% of people asking *any* question here are really doing the wrong thing.
03:30 <****> arjenAU, and 90% of people who aren't asking questions here.
03:30 <****> yep. so just "helping" them sink their ship more efficiently is not my aim
03:31 <****> i'm a mysql trainer and a guy. I can't help helping ;-)
03:31 <****> Simetrical: that's why people here learn to stop asking questions
03:31 <****> proqesi: coz they might learn good stuff??
03:32 <****> that's an intriguing approach
03:32 <****> arjenAU, could you name any situation that you believe would both 1) trigger a question here about adjusting AUTOINCREMENT and 2) be concretely harmful in some fashion?
03:32 <****> Simetrical: google for this topic and you'll find my blog entries
03:33 <****> I have a query with a few natural joins but whenever I add to my where clause "where col != NULL" I get zero rows back
03:34 <****> arjenAU: I'm mostly joking, but partly I'm not because some questions are answered much more easily by google
03:34 <****> The weird thing is when I do "where col = 'onepossibleval'" it works just fine
03:34 <****> proqesi: and everything you read online must be true. certainly.
03:34 <****> arjenAU, I don't see anything relevant to autoincrement Googling on arjen-lentz.livejournal.com, if that's you.
03:34 <****> dampjam: you can't use = or != with NULL you need IS NULL or IS NOT NULL
03:35 <****> Simetrical: that's me
03:35 <****> well if you cross-reference thoroughly you can get a good idea of what is true
03:35 <****> cool - any particular reason?
03:36 <****> http://arjen-lentz.livejournal.com/36015.html and do read the comment thread
03:36 <****> arjenAU, ah, hyphenation is fun. I see now.
03:36 <****> dampjam: yes. NULL is not a value
03:36 <****> then why doesn't it fail hard?
03:37 <****> dampjam: it just evaluates to not true in this case
03:37 <****> NULL is an ugly beast, don't blame MySQL for that.
03:37 <****> if you do where col != it hard fails, and when you do where col != asdfasdf (without any quotes) it fails
03:38 <****> you're saying somehow NULL by itself equals TRUE?
03:38 <****> no
03:38 <****> nor is it false as such
03:38 <****> it's NULL.
03:38 <****> col != NULL evaluates to NULL.
03:38 <****> it's ternary not binary logic
03:38 <****> which is not true ;-)
03:39 <****> Well, if that don't beat all
03:39 <****> I didn't say "false" before, I said "not true" ;-) sorry to be semantically pedantic here, but it's significant
03:39 <****> hehe
03:39 <****> Right.
03:39 <****> Of course I mentally translated that to "false" and thought "that's not right!"
03:39 * Simetrical kicks whoever decided ternary logic would be a good idea for SQL
03:40 <****> without null you'd have to use random values to represent integers that were not set
03:40 <****> and that always sucked in c
03:40 <****> or another column to say whether to pay attention to the column that is set to 0
03:41 <****> dampjam, granted, but it's still confusing.
03:41 <****> dampjam: why did you feel the need to use null for an integer in C?
03:41 * Simetrical isn't sure what you'd do with LEFT JOINs without NULL
03:41 <****> proqesi, his point was exactly that you can't. You have to reserve a value.
03:41 <****> Like 0 or -1.
03:42 <****> Simetrical: well you don't need to, since you don't allocate it
03:42 <****> proqesi, possibly. Depends on the context.
03:43 <****> That's sort of the same concept as NULL
03:43 <****> (not allocating it)
03:45 <****> seekwill, except you can't test it later. You have to hardcode the fact that it's unallocated somewhere, like follow a different code branch that doesn't allocate it.
03:47 <****> arjenAU: is mysql supposed to parse the comments for associating the table spaces back with tables? this is the dump i got from mysqldump... http://rafb.net/p/gFZnKZ88.html
03:47 <****> it seems like it knows which table spaces belong to which table but it doesn't want to associate them together? :-\
03:48 <****> rawake: yes the /*!501xx ... */ is special magic that mysql parses. from that version
03:49 <****> Simetrical: a left join may come up with nulls, and that's fine. nothing wrong with NULL in specific contexts, just need to handle it properly
03:50 <****> I would be vaguely interested in seeing non-SQL-based RDBMS languages. Because SQL kind of sucks, as a language, but there's no real alternative out there.
03:50 <****> arjenAU: ok that's good then... if i restart my cluster mysql says that table spaces are not removed, i have to remove those files manually... do you know where those files are found? for instance i have ts_1.dat but i looked through my /var/lib/mysql-cluster dir and it didn't create a file with that name so i guess it has its own way of naming things but i don't know where these files are to be found
03:51 <****> sql doesnt really suck
03:51 <****> It tends to be unpredictable and weird. Partly because it tries to sound like English.
03:51 <****> EoN: surprise surprise
03:52 <****> its just that most people aren't highly skilled in it. when getting to high level stuff its incredibly powerful.
03:53 <****> anyone know where tablespaces are found on my disk?
03:57 <****> say I wanted to union columns a,b,c from t1, a,b,d from t2, is there a simple way to keep c and d from being returned in the same column
03:58 <****> or to differentiate which table returned which row anyway
04:03 <****> jcooke, you could return a, b, d, NULL from t1 and a, b, NULL, c from t2, I guess. Not sure why you want a UNION for that.
04:08 <****> is there anykind "replace join"? What I mean is that column gets value of joined column instead of mergeing two tables
04:08 <****> are there any other information_schema tables besides .files or any other hidden tables that we can query?
04:10 <****> Simetrical: sorry I dove out of the conversation re: autoincrements. had to attend a meeting. where did we get?
04:10 <****> thoughtful, nowhere.
04:10 <****> good place to be. very zen.
04:11 <****> i think you thought we were being too harsh on abstrakt?
04:11 <****> Yes.
04:12 <****> i had a script a long time ago that made daily / weekly / and monthly backups of your mysql databases into a folder but i don't remember what it was called or even if it was a php script, it could have been just a shell script that you run daily... anyone know what i'm talking about?
04:13 <****> `date`-backup.sql ?
04:13 <****> *nods* no-one should be beyond critical feedback, so i thank you for offering it. but something i'd like you to think about is that i (and maybe others) was offering the same type of feedback to abstrakt. it was meant to be useful, and it would have been great if it had kicked off a useful conversation. it didn't. that happens.
04:15 <****> thoughtful, my point is that I question the usefulness of the feedback in proportion to the emphasis given to it.
04:15 <****> I am beyond critical feedback
04:15 <****> Like.... waaaaaaaaay beyond it
04:16 <****> seekwill: the shirt you wearing makes your butt look huge
04:16 * seekwill takes off shirt
04:16 * blobaugh pukes
04:16 <****> *shrugs* aside from seekwill, we can all sometimes use someone saying, "i want to answer your question, but the fact that you're asking *that* question makes me wonder what else might be going on".
04:17 <****> I'm wondering if someone could help me, i want to do a query which groups the total sum of all transactions grouped by transaction date... however it turns out none of it balances with the banking data because the banking settles at 6.30pm each night. So i need to group by date where 1 day is 6.30pm to 6.30 pm???
04:17 <****> thoughtful, I agree, and do so myself. It was the particular issue that I was questioning, not the general idea.
04:19 <****> vTwo: I would create a column called business_date and store that information in it
Total 31 pages. You are browsing page 5/31.
First :: Prev :: [...] [3] [4] [5] [6] [7] [...] :: Next :: Last