Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "sqlite 3"
-
A little late but whatever.
About half a year ago, I started working on setting up self hosted (slippy) maps. For one, because of privacy reasons, for two, because it'd be in my own control and I could, with enough knowledge, be entirely in control of how this would work.
While the process has been going on for hours every day for about half a year (with regular exceptions), I'll briefly lay out what I've accomplished.
I started with the OpenMapTiles project and tried to implement it myself. This went well but there were two major pitfalls:
1. It worked postgres database based. This is fine but when you want to have the entire world.... the queries took insanely long (minutes, at lower zoom levels) and quite intimate postgres/tooling knowledge was required, which I don't have.
2. Due to the long queries and such, the performance was so bad that the maps could take minutes to render and when you'd want that in production... yeah, no.
After quite some time I finally let that idea sail and started looking into the MBTiles solution; generating sqlite databases of geojson features. Very fast data serving but the rendering can take quite some time.
After some more months, I finally got the hang of it to the point that I automated 50-70 percent of the entire process. The one problem? It takes a shitload of resources and time to generate a worldwide mbtiles database.
After infinite numbers of trial and error, I figured out that one can devide a 'render' (mbtiles aka sqlite database) into multiple layers (one for building data, one for water, one for roads and so on), so I started doing renders that way.
Result? Styling became way more easy and logical and one could pick specific data to display; only want to display the roads? Its way more simple this way. (Not impossible otherwise but figuring out how that works... Good luck).
Started rendering all the countries, continents and such this way and while this seemed like a great idea; the entire world is at 3-4 percent after about a month. And while 40-70 percent generates 10 times as fast, that's still way too slow.
Then, I figured out that you can fetch data per individual layer/source. Thus, I could render every layer separately which is way faster.
Tried that with a few very tiny datasets and bam, it works. (And still very fast).
So, now, I'm generating all layers per continent. I want to do it world based but figured out that that's just not manageable with my resources/budget.
Next to that, I'm working on an API which will have exactly the features I want/need!13 -
Amazing! My joke functionality worked and the server delivered it's content successfully to the client. The joke: malloc is wrapped to give that message and retry IMMEDIATELY. Expectation is that the computer that was already in panic mode gets even fucked up more because it's out of memory. My malloc is literally while((ptr=malloc()} == NULL) { show_warning()
;malloc();}. Imagine if it didn't give that warning, I would've never known that a malloc failed. Who checks their freaking malloc result? You should, but i do not see much people doing it.
The previous crash on screen is what happens if you're doing a get instead of a post. I just declare my server app indestructible btw. Ffs!5 -
Contex: Working on a c++ frankenstein code (mixture of legacy and new stuff whith things depending on the client using it)
User Story: Migration from oracle to SQLite for half of the DB data
Summoner: One client wants to keep using legacy for now, therefore we need an strategy chooser templated singleton...
Satan 666 = Singletons + Static methods + Different compilation units
Result: 3/4 of the files of the full backend being modified for the migration.
Conclusion: When will be loaded on production company will probably lose many clients due to unspected bugs everywhere.
Insert potato here2 -
Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.3 -
Just spent 3 fucking hours trying to find out why my tests are failing. I'm mocking ef with an in memory sqlite dB as THE FUCKING. Net docs say to.
My code does a simple decimal comparison in a linq statement and returns bullshit. Why? Sqlite does not have a decimal type, it does some sort of BULLSHIT to convert it into some sort of text value.
I change all my models to use doubles instead of decimals and all my tests turn green.
WTF IS THIS SHIT. If it doesn't work don't tell me to use it. I expect better of the. Net docs. Wtf are they doing.3 -
MySejahtera is not a good appliaction at all! They just use Sqlite or Shared Preferences in the app for keeping the data local. (Just local?) As soon as you clear cache or data, The user no longer exist! Like wtf ?
So I decompile the app and review the source code, the code is not even properly obfuscated(That's why I can read it). There's a part of the code on a for loop went
```
for (int i = 3; i < array.length(); i++)
{
for (int j = 2; i > array.length() *2; j ++ )
{
onScan();
}
}
```
Which is unacceptable!
First , why nested for loops?
Second, instead of declare 'array.length()' multiple times why not declared it global for once?
No wonder the initial state of the app is buggy as hell.8 -
I thought I had to VARCHAR in non-SQLite RDBMS. I was wrong. There is TEXT.
1. PostGres seems to work better with TEXT.
2. There is an ORM that forces VARCHAR (255) by default.
3. But you can go over the limit without throwing errors.1