Updates tagged with sql on Rainbow Dash Network!
rozzin: RT @mjd Now that's funny: https://boingboing.net/2019/08/14/geeks-idea-to-get-null-l.html #SQL
rozzin's status on Thursday, 15-Aug-19 06:02:02 UTC
RT @mjd Now that's funny: https://boingboing.net/2019/08/14/geeks-idea-to-get-null-l.html #SQL
mjd: Now that's funny: https://boingboing.net/2019/08/14/geeks-idea-to-get-null-l.html #SQL
mjd's status on Thursday, 15-Aug-19 02:40:52 UTC
Now that's funny: https://boingboing.net/2019/08/14/geeks-idea-to-get-null-l.html #SQL
roland: Found a #SQL query for !gnusocial to remote #UTM #click-tracking: UPDATE `file` SET `url` = SUBSTRING_INDEX(`url`, '?utm_', 1) WHERE `url` LIKE '%?utm_%'
roland's status on Friday, 28-Oct-16 14:21:10 UTC
Found a #SQL query for !gnusocial to remote #UTM #click-tracking: UPDATE `file` SET `url` = SUBSTRING_INDEX(`url`, '?utm_', 1) WHERE `url` LIKE '%?utm_%'
sl: Really nice #SQL #Style #Guide. http://www.sqlstyle.guide/ #programming #database #FAQ
sl's status on Tuesday, 11-Oct-16 15:53:08 UTC
Really nice #SQL #Style #Guide. http://www.sqlstyle.guide/ #programming #database #FAQ
sl: Some developers are so afraid of #SQL #injection, that they do interesting solutions. I tried to search for 'selection' but the search always turns out only for 'ion'. Also if looking dor deletion or insertion search also turns out only for 'ion'. So they're stripping the SQL commands from user input which they're so afraid of. Interesting way to deal with the issue. But doing that basically introduced usability issues which can be counted as bug. High five for your security team. This also reminds me from services which strips all ' from strings, just to be sure. They're not stripping drop or or create table commands, interesting logic there. Probably the user account doesn't have rights to drop or create tables, because those aren't being filtered.
sl's status on Sunday, 24-Jul-16 13:13:14 UTC
Some developers are so afraid of #SQL #injection, that they do interesting solutions. I tried to search for 'selection' but the search always turns out only for 'ion'. Also if looking dor deletion or insertion search also turns out only for 'ion'. So they're stripping the SQL commands from user input which they're so afraid of. Interesting way to deal with the issue. But doing that basically introduced usability issues which can be counted as bug. High five for your security team. This also reminds me from services which strips all ' from strings, just to be sure. They're not stripping drop or or create table commands, interesting logic there. Probably the user account doesn't have rights to drop or create tables, because those aren't being filtered.
mjd: Todays tech tip: gPodder doesn't let you search episode title/descriptions. Presuming you can write #SQL queries (and who in this world of tech-literate, digital native millennials can't?) open ~/gPodder/Database with http://sqlitebrowser.org/
mjd's status on Friday, 01-Jul-16 02:26:00 UTC
Todays tech tip: gPodder doesn't let you search episode title/descriptions. Presuming you can write #SQL queries (and who in this world of tech-literate, digital native millennials can't?) open ~/gPodder/Database with http://sqlitebrowser.org/
mcscx2old: RT @roland For the last 3 (!) days (including today) I tried to fix the problem that while the #JPA is merging (similar to UPDATE #SQL statement) entities, some tables got filled with new rows (search for "eclipselink insert instead update") which leaves orphaned rows behind. I could enable orphanRemoval=true but that only adds another performance penalty. So I decided to switch to #Hibernate instead of remaining with #EclipseLink. cc !java
mcscx2old's status on Sunday, 06-Mar-16 20:41:41 UTC
RT @roland For the last 3 (!) days (including today) I tried to fix the problem that while the #JPA is merging (similar to UPDATE #SQL statement) entities, some tables got filled with new rows (search for "eclipselink insert instead update") which leaves orphaned rows behind. I could enable orphanRemoval=true but that only adds another performance penalty. So I decided to switch to #Hibernate instead of remaining with #EclipseLink. cc !java
roland: For the last 3 (!) days (including today) I tried to fix the problem that while the #JPA is merging (similar to UPDATE #SQL statement) entities, some tables got filled with new rows (search for "eclipselink insert instead update") which leaves orphaned rows behind. I could enable orphanRemoval=true but that only adds another performance penalty. So I decided to switch to #Hibernate instead of remaining with #EclipseLink. cc !java
roland's status on Sunday, 06-Mar-16 18:46:34 UTC
For the last 3 (!) days (including today) I tried to fix the problem that while the #JPA is merging (similar to UPDATE #SQL statement) entities, some tables got filled with new rows (search for "eclipselink insert instead update") which leaves orphaned rows behind. I could enable orphanRemoval=true but that only adds another performance penalty. So I decided to switch to #Hibernate instead of remaining with #EclipseLink. cc !java
mcscx's status on Saturday, 14-Nov-15 17:31:31 UTC
@deavmi and #sql ;-)
deleteme: Ща расскажу забавную вещь. Работаю тут с SQLite. Нужно сделать проверку именно существования таблицы name. Ну и пишу "SELECT name FROM sqlite_master;". Прокатывает. Ладно, нужно проверить другую. Пишу "SELECT other FROM sqlite_master;" и не могу понять почему не работает. Оказалось, что нужно "SELECT name FROM sqlite_master WHERE name='other';". А первое знаете почему работало? Потому что в таблице sqlite_master колонка названий таблиц называется name. Ну он и выбирал все. #программирование #sql
deleteme's status on Tuesday, 06-May-14 13:27:35 UTC
Ща расскажу забавную вещь. Работаю тут с SQLite. Нужно сделать проверку именно существования таблицы name. Ну и пишу "SELECT name FROM sqlite_master;". Прокатывает. Ладно, нужно проверить другую. Пишу "SELECT other FROM sqlite_master;" и не могу понять почему не работает. Оказалось, что нужно "SELECT name FROM sqlite_master WHERE name='other';". А первое знаете почему работало? Потому что в таблице sqlite_master колонка названий таблиц называется name. Ну он и выбирал все. #программирование #sql
mjd: Going by posts in the issue queue, people who use Rules are also fond of #SQL. Who needs APIs when you have db_query()? #Drupal #Wrong
mjd's status on Friday, 13-Dec-13 02:27:39 UTC
Going by posts in the issue queue, people who use Rules are also fond of #SQL. Who needs APIs when you have db_query()? #Drupal #Wrong
erkanyilmaz: hm, ok. I am looking e.g. at http://ur1.ca/g1m47 - let's find out via #SQL? select count(*) from conversation;
erkanyilmaz's status on Friday, 15-Nov-13 21:55:28 UTC
hm, ok. I am looking e.g. at http://rainbowdash.net/conversation/3070621 - let's find out via #SQL? select count(*) from conversation;
erkanyilmaz: since @lnxw37@quitter.se 's server is !not online anymore, I assume 1. you will get the #data from a #cache somewhere 2. each SN server has the #licence at bottom of its pages for #reusage <- so I see no problem with topic extraction, though you might also ask @lnxw37 since he may still have a (working) DB and could extract via #SQL faster for you
erkanyilmaz's status on Monday, 16-Sep-13 13:04:08 UTC
since @lnxw37@quitter.se 's server is !not online anymore, I assume 1. you will get the #data from a #cache somewhere 2. each SN server has the #licence at bottom of its pages for #reusage <- so I see no problem with topic extraction, though you might also ask @lnxw37 since he may still have a (working) DB and could extract via #SQL faster for you
toksyuryel: Before I go to bed, I wanted to share this because it makes me happy. http://dpaste.com/749403/ @widget @bitshift !coderpony #SQL
toksyuryel's status on Thursday, 17-May-12 16:31:19 UTC
Before I go to bed, I wanted to share this because it makes me happy. http://dpaste.com/749403/ @widget @bitshift !coderpony #SQL
toksyuryel: Pre-caching the path instead of generating it dynamically seems to only improve cached performance (though the improvement there is dramatic). In some cases the uncached performance was actually *worse* than generating the path in a WITH RECURSIVE block. http://pgsql.privatepaste.com/60741d539f @bitshift @widget !coderpony #SQL
toksyuryel's status on Monday, 14-May-12 09:32:33 UTC
Pre-caching the path instead of generating it dynamically seems to only improve cached performance (though the improvement there is dramatic). In some cases the uncached performance was actually *worse* than generating the path in a WITH RECURSIVE block. http://pgsql.privatepaste.com/60741d539f @bitshift @widget !coderpony #SQL
toksyuryel: So, first test: building the paths in a WITH RECURSIVE block under normal settings. Test shows that this is, indeed, unacceptably slow but cached performance is phenomenal until the thread gets monstrously huge; as real world threads will never get as big as even the smallest thread in this sample, and certainly won't be so spread out, I consider the cached performance to be acceptable but I'd like something better for uncached performance. Now let's test it with the pre-computed paths. http://pgsql.privatepaste.com/205d6138f2 @bitshift @widget !coderpony #SQL
toksyuryel's status on Monday, 14-May-12 09:10:37 UTC
So, first test: building the paths in a WITH RECURSIVE block under normal settings. Test shows that this is, indeed, unacceptably slow but cached performance is phenomenal until the thread gets monstrously huge; as real world threads will never get as big as even the smallest thread in this sample, and certainly won't be so spread out, I consider the cached performance to be acceptable but I'd like something better for uncached performance. Now let's test it with the pre-computed paths. http://pgsql.privatepaste.com/205d6138f2 @bitshift @widget !coderpony #SQL
toksyuryel: Hm, that was done faster than I thought. I estimated the total size would get to be over 5GB but it only got to 4.1GB before it finished. Here's an hour-by-hour breakdown of how long it took to populate the database with over ten million rows: http://dpaste.com/747878/ !coderpony #SQL
toksyuryel's status on Monday, 14-May-12 08:23:58 UTC
Hm, that was done faster than I thought. I estimated the total size would get to be over 5GB but it only got to 4.1GB before it finished. Here's an hour-by-hour breakdown of how long it took to populate the database with over ten million rows: http://dpaste.com/747878/ !coderpony #SQL
toksyuryel: At one million rows, the performance increase of sorting on a pre-computed path is negligible compared to generating the path in a WITH RECURSIVE block. I'll generate another ten million rows overnight and see how that performs tomorrow. #SQL
toksyuryel's status on Sunday, 13-May-12 07:06:30 UTC
At one million rows, the performance increase of sorting on a pre-computed path is negligible compared to generating the path in a WITH RECURSIVE block. I'll generate another ten million rows overnight and see how that performs tomorrow. #SQL
toksyuryel: I can't understand what this error is about. All of my parenthesis seem to line up properly (and it successfully creates the first two tables before the one with the error) and I don't see any misplaced or missing semicolons. Any help? http://dpaste.com/747347/ @bitshift @widget !coderpony #SQL
toksyuryel's status on Sunday, 13-May-12 01:13:01 UTC
I can't understand what this error is about. All of my parenthesis seem to line up properly (and it successfully creates the first two tables before the one with the error) and I don't see any misplaced or missing semicolons. Any help? http://dpaste.com/747347/ @bitshift @widget !coderpony #SQL
toksyuryel: Also I do believe this is the first valid use of an array I've found. #SQL
toksyuryel's status on Saturday, 12-May-12 22:44:26 UTC
Also I do believe this is the first valid use of an array I've found. #SQL
toksyuryel: Alright I figured out what I need to do. If we store the path to each post directly in the database, there is no need for a recursive query. Sorting is fast and fetching posts by thread is also fast, so as long as these are the only things we're doing the result will be fast. Unfortunately testing this against ten million posts will have to wait until tomorrow as implementing this requires updating the schema. I believe that there is nothing further I can do with this database so it's time to drop it and get that new schema in there. #SQL
toksyuryel's status on Saturday, 12-May-12 22:43:22 UTC
Alright I figured out what I need to do. If we store the path to each post directly in the database, there is no need for a recursive query. Sorting is fast and fetching posts by thread is also fast, so as long as these are the only things we're doing the result will be fast. Unfortunately testing this against ten million posts will have to wait until tomorrow as implementing this requires updating the schema. I believe that there is nothing further I can do with this database so it's time to drop it and get that new schema in there. #SQL
toksyuryel: Here's a comparison of uncached performance vs cached performance http://dpaste.com/747276/ @bitshift @widget !coderpony #SQL
toksyuryel's status on Saturday, 12-May-12 20:37:27 UTC
Here's a comparison of uncached performance vs cached performance http://dpaste.com/747276/ @bitshift @widget !coderpony #SQL
toksyuryel: Performance is pretty terrible with ten million rows. I'll have to work out a way to deal with it. #SQL
toksyuryel's status on Saturday, 12-May-12 18:55:22 UTC
Performance is pretty terrible with ten million rows. I'll have to work out a way to deal with it. #SQL
toksyuryel: I wonder how long ago this would have been done if I could use COPY. I started populating four and a half hours ago and it's not even two-thirds done yet. #SQL
toksyuryel's status on Saturday, 12-May-12 00:05:40 UTC
I wonder how long ago this would have been done if I could use COPY. I started populating four and a half hours ago and it's not even two-thirds done yet. #SQL
toksyuryel: Just to see how well this really scales, let's try it with ten million pots. Predictions? #SQL
toksyuryel's status on Friday, 11-May-12 19:35:35 UTC
Just to see how well this really scales, let's try it with ten million pots. Predictions? #SQL
toksyuryel: I'm pretty happy about this. http://dpaste.com/746779/ @widget @bitshift !coderpony #SQL
toksyuryel's status on Friday, 11-May-12 19:14:58 UTC
I'm pretty happy about this. http://dpaste.com/746779/ @widget @bitshift !coderpony #SQL
toksyuryel: Good news: I've identified what sort of query I need in order to output conversations sorted as threads. Bad news: it's WITH RECURSIVE. #SQL
toksyuryel's status on Friday, 11-May-12 13:30:26 UTC
Good news: I've identified what sort of query I need in order to output conversations sorted as threads. Bad news: it's WITH RECURSIVE. #SQL
toksyuryel: Also the fact that CHECK constraints can contain functions in general really. #SQL
toksyuryel's status on Friday, 11-May-12 12:33:50 UTC
Also the fact that CHECK constraints can contain functions in general really. #SQL
toksyuryel: I have discovered that CHECK constraints can contain subqueries if you encapsulate them inside of functions. This opens up so many possibilities. #SQL
toksyuryel's status on Friday, 11-May-12 12:31:49 UTC
I have discovered that CHECK constraints can contain subqueries if you encapsulate them inside of functions. This opens up so many possibilities. #SQL
toksyuryel: Learning quite a few things about what I've been doing wrong. It's great to be able to finally test this stuff. #SQL
toksyuryel's status on Friday, 11-May-12 05:22:41 UTC
Learning quite a few things about what I've been doing wrong. It's great to be able to finally test this stuff. #SQL
toksyuryel: I wonder if it's preferred to chain table joins or use subqueries... it seems like both ultimately accomplish the same thing, just in different ways. Which performs better? Something I'll have to stop being lazy about rebooting to check. (technically I could check now but I don't really want to while still on the LiveCD) #SQL
toksyuryel's status on Thursday, 10-May-12 08:06:19 UTC
I wonder if it's preferred to chain table joins or use subqueries... it seems like both ultimately accomplish the same thing, just in different ways. Which performs better? Something I'll have to stop being lazy about rebooting to check. (technically I could check now but I don't really want to while still on the LiveCD) #SQL
toksyuryel's status on Thursday, 10-May-12 07:59:38 UTC
So many joins @.@ #SQL
toksyuryel: A question arises: if a column references its own table as a foreign key with ON DELETE RESTRICT and just so happens to refer to its own row, is that row simply completely impossible to delete or will it be deleted normally? !coderpony #SQL
toksyuryel's status on Thursday, 10-May-12 00:42:11 UTC
A question arises: if a column references its own table as a foreign key with ON DELETE RESTRICT and just so happens to refer to its own row, is that row simply completely impossible to delete or will it be deleted normally? !coderpony #SQL
toksyuryel: Today's lesson: arrays are evil. http://dpaste.com/745811/ @bitshift !coderpony #SQL
toksyuryel's status on Thursday, 10-May-12 00:31:17 UTC
Today's lesson: arrays are evil. http://dpaste.com/745811/ @bitshift !coderpony #SQL
toksyuryel: Hm, I think my problem is not enough tables. Let's refactor this whole thing and make like a bajilion tables. #SQL
toksyuryel's status on Wednesday, 09-May-12 23:16:47 UTC
Hm, I think my problem is not enough tables. Let's refactor this whole thing and make like a bajilion tables. #SQL
toksyuryel: @bitshift I dunno, I designed half of it while half asleep anyway. Here it is anyway for your perusal http://dpaste.com/745314/ (to anyone just joining us, I'm learning all of this as I go and currently lack the means to test whether I've gotten any of this right, so if the syntax and such is completely wrong it's because I have no idea what I'm doing) !coderpony #SQL
toksyuryel's status on Wednesday, 09-May-12 05:34:44 UTC
@bitshift I dunno, I designed half of it while half asleep anyway. Here it is anyway for your perusal http://dpaste.com/745314/ (to anyone just joining us, I'm learning all of this as I go and currently lack the means to test whether I've gotten any of this right, so if the syntax and such is completely wrong it's because I have no idea what I'm doing) !coderpony #SQL
toksyuryel: @bitshift So how'd I do? :) http://dpaste.com/745233/ !coderpony #SQL
toksyuryel's status on Wednesday, 09-May-12 00:47:20 UTC
@bitshift So how'd I do? :) http://dpaste.com/745233/ !coderpony #SQL
toksyuryel: @toksyuryel @bitshift I realized I forgot some conditionals in one of the stubbed functions, here's a fixed version of that http://dpaste.com/745201/ !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 23:10:58 UTC
@toksyuryel @bitshift I realized I forgot some conditionals in one of the stubbed functions, here's a fixed version of that http://dpaste.com/745201/ !coderpony #SQL
toksyuryel: @bitshift I have stubbed out several functions and created the triggers to demonstrate how I plan to constrain the arrays http://dpaste.com/745194/ !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 23:05:16 UTC
@bitshift I have stubbed out several functions and created the triggers to demonstrate how I plan to constrain the arrays http://dpaste.com/745194/ !coderpony #SQL
toksyuryel: @bitshift Let's see how horribly I botched this one up http://dpaste.com/745169/ !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 22:09:18 UTC
@bitshift Let's see how horribly I botched this one up http://dpaste.com/745169/ !coderpony #SQL
toksyuryel: @bitshift http://dpaste.com/745125/ here's what it looks like now !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 20:50:47 UTC
@bitshift http://dpaste.com/745125/ here's what it looks like now !coderpony #SQL
toksyuryel: @bitshift As long as I'm using dpaste I might as well just post the entire file. Let me know how much I screwed everything up! http://dpaste.com/745106/ !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 20:34:16 UTC
@bitshift As long as I'm using dpaste I might as well just post the entire file. Let me know how much I screwed everything up! http://dpaste.com/745106/ !coderpony #SQL
toksyuryel: Did I do this right? ` replyto bigint CHECK (replyto IS NOT postid AND replyto IS CASE WHEN conversation IS NOT postid THEN NOT NULL),` !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 20:19:16 UTC
Did I do this right? ` replyto bigint CHECK (replyto IS NOT postid AND replyto IS CASE WHEN conversation IS NOT postid THEN NOT NULL),` !coderpony #SQL
toksyuryel: I'm guessing this is invalid... ` mentions text[] CHECK (mentions ALL REFERENCES users),` I'm actually not sure how to do this correctly. How do I write a constraint to compare all the values in an array to rows in a different table? (PostgreSQL) #SQL
toksyuryel's status on Tuesday, 08-May-12 18:50:06 UTC
I'm guessing this is invalid... ` mentions text[] CHECK (mentions ALL REFERENCES users),` I'm actually not sure how to do this correctly. How do I write a constraint to compare all the values in an array to rows in a different table? (PostgreSQL) #SQL
toksyuryel: Using PostgreSQL, can a foreign key reference the table it appears in? Or is there some other way to do this? !coderpony #SQL
toksyuryel's status on Tuesday, 08-May-12 01:48:17 UTC
Using PostgreSQL, can a foreign key reference the table it appears in? Or is there some other way to do this? !coderpony #SQL