**** BEGIN LOGGING AT Tue Feb 16 02:59:59 2016
Feb 16 05:21:10 <Herrie|2> ka6sox: Thnx, it must be something minor, but I don't see it :S
Feb 16 06:32:17 <Tofe> Garfonso: but as soon as I import Foundations, it doesn't seem to ever finish...
Feb 16 06:32:56 <Tofe> Garfonso: there must be a counter somewhere that is wrongly increased statically
Feb 16 20:12:33 <Tofe> Herrie|Veer: ping
Feb 16 20:12:49 <DougReeder> Yo?
Feb 16 20:13:06 <DougReeder> Oh, wait. :-S
Feb 16 20:13:38 <Tofe> DougReeder: well actually you might enlighten me on the subject
Feb 16 20:13:52 <Herrie|Veer> Tofe: pong
Feb 16 20:14:02 <Tofe> I begin to doubt the wiseness of putting geocoding data into db8
Feb 16 20:14:29 <Tofe> or maybe I'm doing it wrong; but it looks like I'm hammering mojodb a bit too hard
Feb 16 20:14:29 <DougReeder> As, in, location associated with area codes?
Feb 16 20:14:31 <Herrie|Veer> Why? Performance?
Feb 16 20:14:35 <Tofe> DougReeder yes
Feb 16 20:14:55 <DougReeder> How many records are we talking about?
Feb 16 20:15:00 <Tofe> Herrie|Veer: well, first, mojodb is still, after a couple of minutes, trying to index the whole thing
Feb 16 20:15:28 <Tofe> DougReeder: let me see. I think it's about 65000
Feb 16 20:15:59 <Tofe> 216754 records
Feb 16 20:16:02 <Herrie|Veer> NoSQL might be an option, not sure how that does performance wise though?
Feb 16 20:16:12 <DougReeder> Hmm, that is getting to the size where a separate datable would be reasonable.
Feb 16 20:16:27 <DougReeder> separate database.
Feb 16 20:16:56 <Herrie|Veer> I mean SQLite
Feb 16 20:17:30 <Tofe> Well, for this very particular case, we don't necessarily need a db, as we can browse the geocodes in a smart way to quickly find it
Feb 16 20:17:48 <DougReeder> And DB8 is generally user data, so we’d like to back DB8 up. That geolocation data shouldn’t be backed up in user accounts.
Feb 16 20:18:13 <Tofe> If we can have a quick way of putting in place a separate db in luneos, why not
Feb 16 20:18:15 <DougReeder> So, in general, I would lean toward a non-DB8 solution.
Feb 16 20:18:42 <DougReeder> LG webOS has a separate “media DB” using the same engine.
Feb 16 20:19:12 <Tofe> Ah, interesting
Feb 16 20:19:23 <Tofe> Would it perform a bit better?
Feb 16 20:19:30 <Tofe> mojodb is still indexing...
Feb 16 20:19:33 <DougReeder> So, a separate database using the DB8 engine or SQLite would be reasonable.
Feb 16 20:20:03 <DougReeder> Probably not order of magnitude.
Feb 16 20:20:36 <Tofe> An important information also is that we could pre-compute a sqlite db when doing the packaging with bitbake
Feb 16 20:20:37 <DougReeder> Taking a minute to insert 200k records doesn’t sound unreasonable to me (but I’m not a DBA).
Feb 16 20:21:10 <Herrie|Veer> Tofe: I think the mediadb is in configurator as well
Feb 16 20:21:17 <Tofe> We are gonna update geocoding data here and there, but the initial 200k records will be well known
Feb 16 20:21:22 <Herrie|Veer> I've seen it somewhere
Feb 16 20:21:46 <Herrie|Veer> Tofe: Updates should be 1000 max at a time I guess, lot less most of the time
Feb 16 20:22:05 <Tofe> Herrie|Veer: a lot less I think also
Feb 16 20:22:30 <Tofe> mojodb still indexing, let's just think about a sqlite solution :p
Feb 16 20:22:59 <Tofe> (we're not gonna initialize the device at first boot during 15min...)
Feb 16 20:25:43 <Tofe> We already have a sqlite3 module for node.js, which is a good point
Feb 16 20:26:00 <DougReeder> A preconfigured DB would be great.  Also, inserting records in the backgroud over the first hour is a reasonable solution.
Feb 16 20:26:29 <DougReeder> Why does Node have a SQLite DB?
Feb 16 20:26:39 <Tofe> dunno
Feb 16 20:27:32 <Tofe> But if I see how to get a preconfigured sqlite db with our build system, I don't know how to do the same with a db8 db...
Feb 16 20:27:44 <Tofe> s/if/while/
Feb 16 20:31:10 <Tofe> Can we access a sqlite db from an app ?
Feb 16 20:31:43 <DougReeder> There’s no mechanism for that.
Feb 16 20:32:56 <Tofe> what about https://github.com/onecrayon/database-webos ?
Feb 16 20:33:20 <DougReeder> You’d proably need a C service to access SQLite, and have the app call the service
Feb 16 20:34:03 <DougReeder> WebSQL databaes, like onecrayons are off in their own little world.
Feb 16 20:34:19 <Tofe> ok; that makes sense
Feb 16 20:34:32 * Tofe don't want to write a node service...
Feb 16 20:35:31 <DougReeder> More particularly, WebSQL was designed as a local cache - there’s no provision for initial data.
Feb 16 20:36:01 <DougReeder> Now, it’s perfectly possible to have the app insert 200k records itself, but that will take a while.
Feb 16 20:36:33 <DougReeder> And WebSQL databases are not accessible by other apps or services, if that matters.
Feb 16 20:36:34 <Tofe> yes, and that's not really what we want: geocoding is meant to be shared among apps
Feb 16 20:37:43 <Tofe> ideally we should use a dedicated pre-configured mojodb
Feb 16 20:38:11 <Tofe> But I don't know how to put that in place (neither the preconfigure part, nor the dedicated)
Feb 16 20:38:25 <DougReeder> If it’s not in the standard DB8 database, we’ll need a dedicated service to access it.
Feb 16 20:39:16 <Tofe> like a com.palm.db fork
Feb 16 20:40:34 <Tofe> all that, just because of some geocoding, it seems like we should find another simpler way
Feb 16 20:42:17 <DougReeder> That’s why SW engineers get paid the moderatly large bucks. Or, in this case, not get paid. :-)
Feb 16 20:54:17 <Herrie|Veer> Tofe: Just thinking out loud here... Couldn't we somehow populate a separate db file (like mediadb) on the build machine & deploy this to device. Indexes etc would then be made on builder, device would only take care of the updates using db8 merges? Shoul
Feb 16 20:54:17 <Herrie|Veer> d reduce the index time drastically?
Feb 16 20:55:26 <DougReeder> Sounds possible, but can you just swap in the files and have DB8 work?
Feb 16 20:56:41 <Tofe> the whole db8 is in /var/db ?
Feb 16 20:57:36 <Tofe> because it's only 25Mb right now
Feb 16 21:11:55 <Herrie|Veer> Tofe: That could be, the limit is 130 MB or so hardcoded afaik
Feb 16 21:12:12 <Herrie|Veer> 25MB for 200000 records sounds plausible to me
Feb 16 21:12:49 <Herrie|Veer> DougReeder: I think if you create a separate DB like media db this might work.
Feb 16 21:13:16 <Herrie|Veer> Not sure though would need to be tested. But doing this centrally instead of on each device makes sense imho
Feb 16 21:13:26 <Herrie|Veer> Feniksa might have some ideas....
Feb 16 21:13:47 <Herrie|Veer> feniksa: ^
Feb 16 21:14:13 <Tofe> Herrie|Veer: currently we don't have any db8 utility compiled natively, afaik
Feb 16 21:14:21 <Tofe> I mean on the build machines
Feb 16 21:16:14 <Tofe> ah wait, we have things like db_something
Feb 16 21:19:58 <Tofe> ... and I have now exceeded db8's quota!
Feb 16 21:21:03 <Tofe> We didn't survive the 13Mb of json geocoding data for China :p
Feb 16 21:21:26 <DougReeder> :-)
Feb 16 21:24:24 <Herrie|Veer> Tofe: Legacy had China too, Google that much more extensive?
Feb 16 21:26:51 <Herrie|Veer> Tofe: I'm not sure if the 1xx MB limit is for the DB while "live" but I suspect that it's at any given time. Could be final DB would be smaller but it exceeds the limit during process.
Feb 16 21:27:14 <Herrie|Veer> Not sure why it's there to start with. 32 bit limitation?
Feb 16 21:27:25 <Herrie|Veer> Or just A design choice?
Feb 16 21:30:14 <Tofe> I've no idea
Feb 16 21:30:33 <Herrie|Veer> Could be just hardcoded value in db8
Feb 16 21:30:49 <Tofe> Maybe they saw that performances are going to decrease if the db grows too big
Feb 16 21:31:12 <DougReeder> That sound plausible.
Feb 16 21:32:51 <Herrie|Veer> Tofe: These choices were made for 2009 mid range hardware ;)
Feb 16 21:33:20 <Herrie|Veer> I doubt that will be still the case on more modern hardware. At least should be less.
Feb 16 21:33:22 <DougReeder> Well, 2010 ;-)
Feb 16 21:33:41 <Herrie|Veer> DougReeder: You get my point :P
Feb 16 21:33:47 * DougReeder nods
Feb 17 02:10:02 <sidotij> just getting ready to install Café Miel on my touchpad... has there been a kernal update since Caffè Marocchino or can I keep using the same one
Feb 17 02:12:19 <sidotij> oh I see... image is the same size... so I should be good
Feb 17 02:31:18 <sidotij> very nice.. quick and responsive
**** ENDING LOGGING AT Wed Feb 17 02:59:59 2016