Notices tagged with sql
-
Now that's funny: https://boingboing.net/2019/08/14/geeks-idea-to-get-null-l.html #SQL
Thursday, 15-Aug-19 02:40:52 UTC from microblog.mjd.id.au at 30°21'41"S 153°6'9"E in context Repeated by rozzin -
Now that's funny: https://boingboing.net/2019/08/14/geeks-idea-to-get-null-l.html #SQL
-
Found a #SQL query for !gnusocial to remote #UTM #click-tracking: UPDATE `file` SET `url` = SUBSTRING_INDEX(`url`, '?utm_', 1) WHERE `url` LIKE '%?utm_%'
-
Really nice #SQL #Style #Guide.
http://www.sqlstyle.guide/
#programming #database #FAQ -
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.
-
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/
-
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
-
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
-
Ща расскажу забавную вещь. Работаю тут с SQLite. Нужно сделать проверку именно существования таблицы name. Ну и пишу "SELECT name FROM sqlite_master;". Прокатывает. Ладно, нужно проверить другую. Пишу "SELECT other FROM sqlite_master;" и не могу понять почему не работает. Оказалось, что нужно "SELECT name FROM sqlite_master WHERE name='other';". А первое знаете почему работало? Потому что в таблице sqlite_master колонка названий таблиц называется name. Ну он и выбирал все. #программирование #sql
-
hm, ok. I am looking e.g. at http://rainbowdash.net/conversation/3070621 - let's find out via #SQL? select count(*) from conversation;
-
erkanyilmaz
not
, lnxw37
, shabgard
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
-
Before I go to bed, I wanted to share this because it makes me happy. http://dpaste.com/749403/ @widget @bitshift !coderpony #SQL
Thursday, 17-May-12 16:31:19 UTC from web -
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
Monday, 14-May-12 09:32:33 UTC from web -
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
Monday, 14-May-12 09:10:37 UTC from web -
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
-
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
Sunday, 13-May-12 07:06:30 UTC from web -
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
-
Also I do believe this is the first valid use of an array I've found. #SQL
Saturday, 12-May-12 22:44:26 UTC from web -
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
-
Here's a comparison of uncached performance vs cached performance http://dpaste.com/747276/ @bitshift @widget !coderpony #SQL
-
Performance is pretty terrible with ten million rows. I'll have to work out a way to deal with it. #SQL
Saturday, 12-May-12 18:55:22 UTC from web -
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
Saturday, 12-May-12 00:05:40 UTC from web -
Just to see how well this really scales, let's try it with ten million pots. Predictions? #SQL
Friday, 11-May-12 19:35:35 UTC from web -
I'm pretty happy about this. http://dpaste.com/746779/ @widget @bitshift !coderpony #SQL
Friday, 11-May-12 19:14:58 UTC from web -
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
Friday, 11-May-12 13:30:26 UTC from web -
Also the fact that CHECK constraints can contain functions in general really. #SQL
Friday, 11-May-12 12:33:50 UTC from web -
I have discovered that CHECK constraints can contain subqueries if you encapsulate them inside of functions. This opens up so many possibilities. #SQL
Friday, 11-May-12 12:31:49 UTC from web -
Learning quite a few things about what I've been doing wrong. It's great to be able to finally test this stuff. #SQL
Friday, 11-May-12 05:22:41 UTC from web
