My Ruby has derailed



  • Ruby on Rails uses SQLite as its default database backend. This creates problems when changing table layouts because SQLite doesn't support deleting columns. So what does RoR do?

    Well, first it loads the entire table into memory. Then it copies each item from the table, one-by-one, into a temporary table. Then it copies the temporary table back using the same method.

    So if you have a table with a billion records and you want to remove a column, it takes over two billion queries, and in that time, every single row from that table will be in memory twice (from the to_a(rray) on the query and in the temporary table).



  • Reading the SQLite site gives me that strange feeling of being in the presence of a crazy person who has not yet flipped out.




  • I'm not sure, however, that a billion rows make a good usecase for SQLite. Isn't PostgreSQL and its like better suited for such sizes?



  • RoR is shit, SQLite is shit.. 2007 called and wants their headlines back.



  • @Ben L. said:

    Ruby on Rails uses SQLite as its default database backend.

    So if you have a table with a billion records and you want to remove a column, it takes over two billion queries

    Well sure, that'd be a gigantic WTF if anyone was silly enough to do something like load more than 100 records into a SQLite instance. There's a hint somewhere in the name.


  • @Vanders said:

    @Ben L. said:
    Ruby on Rails uses SQLite as its default database backend.

    So if you have a table with a billion records and you want to remove a column, it takes over two billion queries

    Well sure, that'd be a gigantic WTF if anyone was silly enough to do something like load more than 100 records into a SQLite instance. There's a hint somewhere in the name.

    SQL-like-a-piggy-ite?



  • I'm not going to defend RoR because I haven't touched anything related to it in a while (read a book about ruby like six years ago) but, if you're using SQLite for a live application, mister, whoever took that decision is TRWTF.

    I mean, really? SQLite in a live system with a billion rows? Whoever made that call has no idea of what they are doing. If this is not a live system, why the hell do you load a database with that much data?

    Anyway, you failed because this is not a WTF. Many frameworks already come with "light" RDBMS, for example, Play comes with H2. Grails comes with HSQLDB (citation needed)



  • @ubersoldat said:

    I'm not going to defend RoR because I haven't touched anything related to it in a while (read a book about ruby like six years ago) but, if you're using SQLite for a live application, mister, whoever took that decision is TRWTF.

    I mean, really? SQLite in a live system with a billion rows? Whoever made that call has no idea of what they are doing. If this is not a live system, why the hell do you load a database with that much data?

    Anyway, you failed because this is not a WTF. Many frameworks already come with "light" RDBMS, for example, Play comes with H2. Grails comes with HSQLDB (citation needed)

    I actually agree with this. I mean, SQLite sucks, but it's really not meant for anything but the silliest, smallest dev environment. I'm much more concerned with the choice of using RoR in the first place.



  • In ascending order of WTF:

    Ruby

    <font size="3">On Rails</font>

    <font size="4">SQLite</font>

    <font size="5">SQLite doesn't support deleting columns</font>

    <font size="6">SQLite table with a billion records</font>



  • according to SQLLite, 2^64 rows possible... in a single file?


  • Trolleybus Mechanic

    @zelmak said:

    according to SQLLite, 2^64 rows possible... in a single file?

    How many of those rows can be XML blobs with multiple rows?



  • @zelmak said:

    according to SQLLite, 2^64 rows possible... in a single file?
    And max db size is 140TB. That is some optimistic craziness.



  • @morbiuswilters said:

    SQLite sucks, but it's really not meant for anything but the silliest, smallest dev environment.
    Well, that explains Firefox.

    <font face="courier new,courier">4/06/2014  18:49         524,288  addons.sqlite
    4/08/2014  14:25         229,376  content-prefs.sqlite
    4/08/2014  18:13       1,048,576  cookies.sqlite
    4/07/2014  18:00          98,304  downloads.sqlite
    4/02/2014  22:30         524,288  extensions.sqlite
    4/08/2014  16:35         491,520  formhistory.sqlite
    4/08/2014  14:25          65,536  permissions.sqlite
    4/08/2014  18:12      10,485,760  places.sqlite
    4/08/2014   9:34         393,216  signons.sqlite
    4/08/2014  16:54       4,554,752  webappsstore.sqlite</font>



  • @zelmak said:

    according to SQLLite, 2^64 rows possible... in a single file?

    "Passengers on the left-hand side will be treated to an breathtaking view of the difference between theory and practice.."


    Maybe the caret is a typo and they mean it will support up to 264 rows?



  • @El_Heffe said:

    @morbiuswilters said:

    SQLite sucks, but it's really not meant for anything but the silliest, smallest dev environment.
    Well, that explains Firefox.

    <font face="courier new,courier">4/06/2014  18:49         524,288  addons.sqlite
    4/08/2014  14:25         229,376  content-prefs.sqlite
    4/08/2014  18:13       1,048,576  cookies.sqlite
    4/07/2014  18:00          98,304  downloads.sqlite
    4/02/2014  22:30         524,288  extensions.sqlite
    4/08/2014  16:35         491,520  formhistory.sqlite
    4/08/2014  14:25          65,536  permissions.sqlite
    4/08/2014  18:12      10,485,760  places.sqlite
    4/08/2014   9:34         393,216  signons.sqlite
    4/08/2014  16:54       4,554,752  webappsstore.sqlite</font>

    Remember when Firefox was going to allow Javascript code running in the browser to create and use its own SQLite databases?



  • @bstorer said:

    @zelmak said:
    according to SQLLite, 2^64 rows possible... in a single file?
    And max db size is 140TB. That is some optimistic craziness.

    *If one of the rows has a 139.9999TB blob in it.



  • @morbiuswilters said:

    @zelmak said:
    according264 to SQLLite, 2^64 rows possible... in a single file?

    "Passengers on the left-hand side will be treated to an breathtaking view of the difference between theory and practice.."


    Don't worry; the SQLite team knows the difference between theory and practice:
    @http://www.sqlite.org/limits.html said:

    Maximum Number Of Rows In A Table

    The theoretical maximum number of rows in a table is 264 (18446744073709551616 or about 1.8e+19). This limit is unreachable since the maximum database size of 140 terabytes will be reached first. A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.



  • @bstorer said:

    @http://www.sqlite.org/limits.html said:
    A 140 terabytes database can hold no more than approximately 1e+13 rows, and then only if there are no indices and if each row contains very little data.
    Well, that sounds very useful.



  • @morbiuswilters said:

    @zelmak said:
    according to SQLLite, 2^64 rows possible... in a single file?

    "Passengers on the left-hand side will be treated to an breathtaking view of the difference between theory and practice.."


    Maybe the caret is a typo and they mean it will support up to 264 rows?

    They're obviously using C syntax. SQLite supports up to 66 rows.



  • @morbiuswilters said:

    @bstorer said:
    @zelmak said:
    according to SQLLite, 2^64 rows possible... in a single file?
    And max db size is 140TB. That is some optimistic craziness.

    *If one of the rows has a 139.9999TB blob in it.

    Nice try, but you're wrong yet again. Max BLOB length is only 2147483647. It's like you're not even reading the documentation:

    @http://www.sqlite.org/limits.html said:

    Maximum length of a string or BLOB

    The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE_MAX_LENGTH. The default value of this macro is 1 billion (1 thousand million or 1,000,000,000). You can raise or lower this value at compile-time using a command-line option like this:

    -DSQLITE_MAX_LENGTH=123456789

    The current implementation will only support a string or BLOB length up to 231-1 or 2147483647. And some built-in functions such as hex() might fail well before that point. In security-sensitive applications it is best not to try to increase the maximum string and blob length. In fact, you might do well to lower the maximum string and blob length to something more in the range of a few million if that is possible.

    During part of SQLite's INSERT and SELECT processing, the complete content of each row in the database is encoded as a single BLOB. So the SQLITE_MAX_LENGTH parameter also determines the maximum number of bytes in a row.



    I'm sorry, but I need to reiterate that last paragraph again, because it's so awesome:

    During part of SQLite's INSERT and SELECT processing, the complete content of each row in the database is encoded as a single BLOB. So the SQLITE_MAX_LENGTH parameter also determines the maximum number of bytes in a row.



  • @bstorer said:

    I'm sorry, but I need to reiterate that last paragraph again, because it's so awesome:

    During part of SQLite's INSERT and SELECT processing, the complete content of each row in the database is encoded as a single BLOB. So the SQLITE_MAX_LENGTH parameter also determines the maximum number of bytes in a row.

    My favorite part was:

    @The Stench of Failure said:

    In security-sensitive applications it is best not to try to increase the maximum string and blob length. In fact, you might do well to lower the maximum string and blob length to something more in the range of a few million if that is possible.

    "Yeah, the default value we chose might kind of suck.. you should probably recompile your version of SQLite to use something slightly less insecure.. or whatever.. Did we mention we're like the 'easy' database? Cuz we are.."

    I notice from their home page that Oracle is a sponsor. Anybody else wonder what the hell Oracle's game is here? They seem to be in the business of propping up every shitty competitor database they can find..



  • @morbiuswilters said:

    I notice from their home page that Oracle is a sponsor. Anybody else wonder what the hell Oracle's game is here? They seem to be in the business of propping up every shitty competitor database they can find..
    Distraction. If the other common databases all suck, Oracle doesn't seem quite as bad. Like taking a shit in the middle of a Thai restaurant.

    Seriously, though, in what way is SQLite even remotely a competitor to Oracle? Might as well throw them a few table scraps in the hopes that they stumble upon something worthwhile, at which point Oracle can buy it up for less than they spend on their America's Cup boat.


  • Considered Harmful

    @morbiuswilters said:

    @El_Heffe said:

    @morbiuswilters said:

    SQLite sucks, but it's really not meant for anything but the silliest, smallest dev environment.
    Well, that explains Firefox.

    <font face="courier new,courier">4/06/2014  18:49         524,288  addons.sqlite
    4/08/2014  14:25         229,376  content-prefs.sqlite
    4/08/2014  18:13       1,048,576  cookies.sqlite
    4/07/2014  18:00          98,304  downloads.sqlite
    4/02/2014  22:30         524,288  extensions.sqlite
    4/08/2014  16:35         491,520  formhistory.sqlite
    4/08/2014  14:25          65,536  permissions.sqlite
    4/08/2014  18:12      10,485,760  places.sqlite
    4/08/2014   9:34         393,216  signons.sqlite
    4/08/2014  16:54       4,554,752  webappsstore.sqlite</font>

    Remember when Firefox was going to allow Javascript code running in the browser to create and use its own SQLite databases?

    Actually, Firefox is the only major browser that didn't implement Web SQL, choosing instead to implement the shitstain NoSQL database IndexedDB.
    Edit: OK I guess IE skipped it too. But neither standard is ubiquitous enough for use, and IndexedDB's API is awful, requiring minimum two callbacks for every operation.



  • @bstorer said:

    Seriously, though, in what way is SQLite even remotely a competitor to Oracle?

    I dunno, supporting 140TB databases? Larry Ellison better stop polishing his schooner and get to work.

    @bstorer said:

    ...at which point Oracle can buy it up for less than they spend on their America's Cup boat.

    No way, maaaaan.. SQLite is Open Source. That means it will never get bought by the man!



  • @joe.edwards said:

    Actually, Firefox is the only major browser that didn't implement Web SQL, choosing instead to implement the shitstain NoSQL database IndexedDB.
    Edit: OK I guess IE skipped it too. But neither standard is ubiquitous enough for use, and IndexedDB's API is awful, requiring minimum two callbacks for every operation.

    They're both awful and Web SQL isn't even a standard any more, having been dropped by the W3C. That said, I recalled Mozilla being a big, early supporter of the idea of web apps being able to use SQLite databases, but perhaps I'm just remembering incorrectly. Or maybe history is wrong. Yes, that's the ticket.



  • @morbiuswilters said:

    @bstorer said:
    Seriously, though, in what way is SQLite even remotely a competitor to Oracle?

    I dunno, supporting 140TB databases? Larry Ellison better stop polishing his schooner and get to work.

    "Marketing division? Update your ad copy. From now on we support 141TB databases. ... Of course we can't really handle 141TB; who gives a damn? It's just marketing bullshit. ... What do you mean we have customers who will actually want that? Can't we tell them they have to upgrade to a new version first? ... We used that line already? Alright, alright. Tell them we can handle 141TB databases, but the rows can't contain any data. ... Yeah, I know. It's a fucking brilliant excuse. I stole it from one of those open source pieces of shit we sponsor. ... I don't know what it's called. That one Ruby on Rails defaults to. It's got SQL in the name, I know that much. Maybe it's called MySQL? ... We do? When the hell did we buy that? Nevermind, I don't really care. Anyway, just update the brochure, slap a new lower-case letter after the version number, and get it out the door. I gotta get back to the boat. That jib won't trim itself, you know."



  • @morbiuswilters said:

    They're both awful and Web SQL isn't even a standard any more, having been dropped by the W3C.
    Which is how you know it was an utterly unredeemable piece of shit. Those fuckers are still clinging on to MathML and VoiceXML.



  • @bstorer said:

    @morbiuswilters said:
    They're both awful and Web SQL isn't even a standard any more, having been dropped by the W3C.
    Which is how you know it was an utterly unredeemable piece of shit. Those fuckers are still clinging on to MathML and VoiceXML.

    It's hard to imagine an industry which would operate better if the DMV was in charge, but web standards is one. The DMV drones wouldn't even need technical training, just the ability to produce reams of nonsense nobody will read and a desire to see the very notion of human dignity denuded and mocked. And they already have those, so..



  • @bstorer said:

    "I gotta get back to the boat. That jib won't trim itself, you know."

    Wow, and you thought it was annoying when your boss tried to explain asynchronous I/O to the engineers using dump trucks as an analogy..



  • @Vanders said:

    @Ben L. said:
    Ruby on Rails uses SQLite as its default database backend.

    So if you have a table with a billion records and you want to remove a column, it takes over two billion queries

    Well sure, that'd be a gigantic WTF if anyone was silly enough to do something like load more than 100 records into a SQLite instance. There's a hint somewhere in the name.

    SQLite is perfectly fine with millions of rows. It is also much faster than any server-based database engine with them. The "lite" means that it's simple and does not need much setup. It does not mean that it would be slow nor that it would not scale.

    There is one thing in which SQLite does indeed not scale. It can only have one writer at a time. Per whole database. And until recently no reader while writing (in fact often still, because the write-ahead log that allows it has it's disadvantages so not everybody enables it). But if you have big data that you need to query with complex queries and don't need to update it often, SQLite is good option. And it's good option for development and testing, because it does not require any setup.

    At $work we need to process some data. Some of it needs to be programmed in Turing-complete language, but most of it is best expressed as long sequence of SQL queries. So we have application that reads millions of rows from database, creates intermediate results with millions of rows and reads them over again and again. It's pretty fast. No database server could do that simply because it has more overhead moving the data between the processes and more locking overhead due to the finer-grained locks. Of course it's offline batch process, so we don't need other processes to access the data when it's being processed.

    It also has one additional condition. SQLite has rather large transaction overhead. So to get good performance, you have to do big chunks of work in transactions (which we do).

    Now, it's true that SQLite does not have `drop column`. But it does have insert into ... select. And it does have rename table. So dropping table can be implemented by begin, renaming the table, copying the good columns over, dropping the old table and commit. If Ruby on Rails can't do that, the WTF is squarely on it's side.



  • @morbiuswilters said:

    the ability to produce reams of nonsense
     

    I read "realms of nonsense" and was momentarily in awe at the thought of entire planes of existence comprising infinite stretches of folly.

     

    It is not certain whether this cosmos isn't one of those. 



  • @Bulb said:

    SQLite is a good option. And it's a good option for development and testing, because it does not require any setup.

    At $work we need to process some data. Some of it needs to be programmed in a Turing-complete language, but most of it is best expressed as a long sequence of SQL queries. So we have an application that reads millions of rows from the database, creates intermediate results with millions of rows and [...] Of course it's an offline batch process, so we don't need other processes to access the data when it's being processed.

     

    Bold additions mine.

    I'm not trying to be cute, just the linguist in me is often amused and intrigued by an apparent lack of certain words in eastern-european and russian languages (my grammar terminology is sketchy. it's the "(in)definite article", I think?).

     



  • @Bulb said:

    So dropping table can be implemented by begin, renaming the table, copying the good columns over, dropping the old table and commit.

    Does it actually support DDLs in transactions? Because MySQL does not and it burns my grits.



  • @dhromed said:

    @Bulb said:

    SQLite is a good option. And it's a good option for development and testing, because it does not require any setup.

    At $work we need to process some data. Some of it needs to be programmed in a Turing-complete language, but most of it is best expressed as a long sequence of SQL queries. So we have an application that reads millions of rows from the database, creates intermediate results with millions of rows and [...] Of course it's an offline batch process, so we don't need other processes to access the data when it's being processed.

     

    Bold additions mine.

    I'm not trying to be cute, just the linguist in me is often amused and intrigued by an apparent lack of certain words in eastern-european and russian languages (my grammar terminology is sketchy. it's the "(in)definite article", I think?).

    The upshot is that when you want to do an insulting impersonation of Eastern Europeans, it's pretty easy. Now try mocking the Dutch or the Congolese or what-have-you. (Well, it would be easy for you because you are Dutch, but the rest of just have to work some comment about dykes or windmills in there.)

    Some ethnicities lend themselves to easy disparagement. Take the French: just do a nasally accent and start with "Oui Oui" and everyone instantly gets what you are trying to do, without the need to put on pancake capitulationface. Australia? Start with a British accent, knock off about 40 IQ points, add an ear-splitting nasally quality and work in something about dingoes or putting more shrimp on the barbie. I know it's a cruel stereotype, but it really does help to be drunk while trying to act Australian. And I mean drunk. Just get that BAC up to 0.3 and let your body do what comes natural; whatever comes out will be authentically Oz.

    Of course, it can be kind of hard to convey, say, New Zealander instead of Aussie. I tend to ease up a bit on the foetal alcohol syndrome angle (but don't eliminate it entirely) and name-drop some sheep terms. Yes, Australia has sheep, too, but sheep are kind of a trademark for NZ. Like, if I say "obsessed with poop", everyone knows I mean Germany, even if there are coprophagists in other countries.



  • @morbiuswilters said:

    @Bulb said:
    So dropping table can be implemented by begin, renaming the table, copying the good columns over, dropping the old table and commit.

    Does it actually support DDLs in transactions? Because MySQL does not and it burns my grits.

    Of course it does. SQLite is a high-performance database meant for millions of rows and gigs of data. It's not some shoddy, half-assed database like MySQL or Oracle.



  • @Bulb said:

    Now, it's true that SQLite does not have `drop column`. But it does have insert into ... select. And it does have rename table. So dropping table can be implemented by begin, renaming the table, copying the good columns over, dropping the old table and commit.
    From the official SQLite website:

    You have a table named "t1" with columns "a", "b", and "c" and you want to delete column "c" from this table

    CREATE TEMPORARY TABLE t1_backup(a,b);
    INSERT INTO t1_backup SELECT a,b FROM t1;
    DROP TABLE t1;
    CREATE TABLE t1(a,b);
    INSERT INTO t1 SELECT a,b FROM t1_backup;
    DROP TABLE t1_backup;

    That's insane. It works (for certain definitons of "works") but it is insane.



  • @El_Heffe said:

    @Bulb said:

    Now, it's true that SQLite does not have drop column. But it does have insert into ... select. And it does have rename table. So dropping table can be implemented by begin, renaming the table, copying the good columns over, dropping the old table and commit.
    From the official SQLite website:

    You have a table named "t1" with columns "a", "b", and "c" and you want to delete column "c" from
    this table

    CREATE TEMPORARY TABLE t1_backup(a,b);
    INSERT INTO t1_backup SELECT a,b FROM t1;
    DROP TABLE t1;
    CREATE TABLE t1(a,b);
    INSERT INTO t1 SELECT a,b FROM t1_backup;
    DROP TABLE t1_backup;

    That's insane. It works (for certain definitons of "works") but it is insane.

    The weird thing is, they have a way to do this. I mean, it's shitty, but why not just create a "drop column" command that runs the above? Are you telling me most SQLite users would notice? You could steal most SQLite users' homes and they'd just return to the dirt lot every night, stand approximately where the bathroom used to be and brush their teeth, then go lay down next to the pack of feral dogs, where their bed used to be.


    No offense, Bulb. Wait, you're Czech so that probably didn't make any sense to you anyway. Replace "home" with "collective turnip farm" and "bathroom" with "rusted-out, East German tractor". The thing about the feral dogs can probably stay as-is.



  • @morbiuswilters said:

    The weird thing is, they have a way to do this. I mean, it's shitty, but why not just create a "drop column" command that runs the above? Are you telling me most SQLite users would notice?
    Why would anyone ever want to delete a column? Just remove any index on it and forget it's there. Next time you need to add a column, just reuse the one you already have. SQLite doesn't enforce data types or lengths, so you'll be good to go.



  • @bstorer said:

    @morbiuswilters said:
    The weird thing is, they have a way to do this. I mean, it's shitty, but why not just create a "drop column" command that runs the above? Are you telling me most SQLite users would notice?
    Why would anyone ever want to delete a column? Just remove any index on it and forget it's there. Next time you need to add a column, just reuse the one you already have. SQLite doesn't enforce data types or lengths, so you'll be good to go.

    Wow, that's so loose your mother might need to sue them for trademark infringement.



  • @morbiuswilters said:

    @bstorer said:
    @morbiuswilters said:
    The weird thing is, they have a way to do this. I mean, it's shitty, but why not just create a "drop column" command that runs the above? Are you telling me most SQLite users would notice?
    Why would anyone ever want to delete a column? Just remove any index on it and forget it's there. Next time you need to add a column, just reuse the one you already have. SQLite doesn't enforce data types or lengths, so you'll be good to go.

    Wow, that's so loose your mother might need to sue them for trademark infringement.

    She can't sue; she's in the public domain.



  • @bstorer said:

    @morbiuswilters said:
    The weird thing is, they have a way to do this. I mean, it's shitty, but why not just create a "drop column" command that runs the above? Are you telling me most SQLite users would notice?
    Why would anyone ever want to delete a column? Just remove any index on it and forget it's there. Next time you need to add a column, just reuse the one you already have. SQLite doesn't enforce data types or lengths, so you'll be good to go.
    SQLite lets me insert a string into a database column of type integer!
    This is a feature, not a bug.

    What is the maximum size of a VARCHAR in SQLite?
    SQLite does not enforce the length of a VARCHAR. You can declare a VARCHAR(10) and SQLite will be happy to let you put 500 characters in it. And it will keep all 500 characters intact.



  • @morbiuswilters said:

    work in something about dingoes or putting more shrimp on the barbie
    That's "prawns", you nong. Only a nuff-nuff who believes we think Foster's is beer would ever say "shrimp".



  • @flabdablet said:

    @morbiuswilters said:
    work in something about dingoes or putting more shrimp on the barbie
    That's "prawns", you nong. Only a nuff-nuff who believes we think Foster's is beer would ever say "shrimp".
    Nope, sorry. According to your embassy, it's "shrimp."



  • @morbiuswilters said:

    Of course, it can be kind of hard to convey, say, New Zealander instead of Aussie.

    The easiest way to do a New Zealand accent is to swap i's for u's and e's for i's for example, "fish" becomes "fush"; "deck" becomes "dick". (It's probably not what you think when I Kiwi suggests you spend the evening sat on his dick.)



  • @bstorer said:

    @morbiuswilters said:
    They're both awful and Web SQL isn't even a standard any more, having been dropped by the W3C.
    Which is how you know it was an utterly unredeemable piece of shit. Those fuckers are still clinging on to MathML and VoiceXML.
    The official reason they dropped it was because all three major browser codebases' first, gutteral reaction to Web SQL was #include <sqlite.h> and the W3C has some silly requirement about "multiple distinct, interoperable implementations" rather than accepting that SQLite is the god damn standard now.



  • @RTapeLoadingError said:

    "deck" becomes "dick". (It's probably not what you think when I Kiwi suggests you spend the evening sat on his dick.)
    It must be difficult to be gay in New Zealand.  You just get a bunch of guys sitting on your deck.



  • @morbiuswilters said:

    @El_Heffe said:

    @morbiuswilters said:

    SQLite sucks, but it's really not meant for anything but the silliest, smallest dev environment.
    Well, that explains Firefox.

    <font face="courier new,courier">4/06/2014  18:49         524,288  addons.sqlite
    4/08/2014  14:25         229,376  content-prefs.sqlite
    4/08/2014  18:13       1,048,576  cookies.sqlite
    4/07/2014  18:00          98,304  downloads.sqlite
    4/02/2014  22:30         524,288  extensions.sqlite
    4/08/2014  16:35         491,520  formhistory.sqlite
    4/08/2014  14:25          65,536  permissions.sqlite
    4/08/2014  18:12      10,485,760  places.sqlite
    4/08/2014   9:34         393,216  signons.sqlite
    4/08/2014  16:54       4,554,752  webappsstore.sqlite</font>

    Remember when Firefox was going to allow Javascript code running in the browser to create and use its own SQLite databases?

    Remember when Firefox was controlled by people not certifiably insane?


  • Considered Harmful

    @dhromed said:

    my grammar terminology is sketchy. it's the "(in)definite article", I think?

    They're articles. The definite article refers to a specific thing (the big purple dildo), the indefinite article could refer to any of a certain type of thing (a big purple dildo).



  • @The_Assimilator said:

    @morbiuswilters said:
    @El_Heffe said:

    @morbiuswilters said:

    SQLite sucks, but it's really not meant for anything but the silliest, smallest dev environment.
    Well, that explains Firefox.

    <font face="courier new,courier">4/06/2014  18:49         524,288  addons.sqlite
    4/08/2014  14:25         229,376  content-prefs.sqlite
    4/08/2014  18:13       1,048,576  cookies.sqlite
    4/07/2014  18:00          98,304  downloads.sqlite
    4/02/2014  22:30         524,288  extensions.sqlite
    4/08/2014  16:35         491,520  formhistory.sqlite
    4/08/2014  14:25          65,536  permissions.sqlite
    4/08/2014  18:12      10,485,760  places.sqlite
    4/08/2014   9:34         393,216  signons.sqlite
    4/08/2014  16:54       4,554,752  webappsstore.sqlite</font>

    Remember when Firefox was going to allow Javascript code running in the browser to create and use its own SQLite databases?

    Remember when Firefox was controlled by people not certifiably insane?

    Yes. It was called Phoenix and nobody within Mozilla was paying any attention to it because they still believed Netscape 6 was the way forward.


  • @dhromed said:

    @Bulb said:

    SQLite is a good option. And it's a good option for development and testing, because it does not require any setup.

    At $work we need to process some data. Some of it needs to be programmed in a Turing-complete language, but most of it is best expressed as a long sequence of SQL queries. So we have an application that reads millions of rows from the database, creates intermediate results with millions of rows and [...] Of course it's an offline batch process, so we don't need other processes to access the data when it's being processed.

     

    Bold additions mine.

    I'm not trying to be cute, just the linguist in me is often amused and intrigued by an apparent lack of certain words in eastern-european and russian languages (my grammar terminology is sketchy. it's the "(in)definite article", I think?).

     

    Those are just called articles, I think.

Log in to reply