Re: [sqlite] SQLite Database Browser officially moved to GitHub
On 2014-05-20 21:35, Tim Streater wrote:
I followed the instructions at the github URL, and was able to build
sqlitebrowser. Couple of points:
1) Warn folks not to have a single-quote (') in their path, it causes
the make of sqlitebrowser to fail. I moved the folder elsewhere and
redid the qmake, make, steps and it completed.
Thanks, that's good info. Created a bug report for it:
https://github.com/sqlitebrowser/sqlitebrowser/issues/10
... and updated GitHub+website with the info (including working on OSX
10.9).
2) It took 57 minutes on a 2011 2.3GHz Core i5 Mini to build qt
(whatever that may be) although perhaps a bit of that might have been
it waiting for me to agree the licence (I was out of the room). That
wound the CPU up to 400%, the fan to 6000rpm, and the core temp to
90C. Still, it seems fine.
Yeah, Qt is huge. ;) It's a (generally) very high quality cross
platform window library. There are smaller alternatives, but the
end result from them (in my opinion) just isn't as good.
I also had to install brew, but that was quite quick.
Now I'll have to figure out how to use it.
Hopefully it's mostly straight forward. If you encounter bugs
or have suggestions, please feel free to open an Issue on GitHub
(preferred) or email. :)
Regards and best wishes,
Justin Clift
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite Database Browser officially moved to GitHub
Well, Apple uses special CPU compression technology to get more work done in the same amount of time... ;) On Tue, May 20, 2014 at 5:17 PM, RSmith wrote: > > On 2014/05/20 23:37, Tim Streater wrote: > >> Sorry, should have said I'm on OS X Mavericks 10.9.3. >> > > We know... no other OS would report CPU usage as 400%... :) > > > > > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Scott Robison ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite Database Browser officially moved to GitHub
On 2014/05/20 23:37, Tim Streater wrote: Sorry, should have said I'm on OS X Mavericks 10.9.3. We know... no other OS would report CPU usage as 400%... :) ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite Database Browser officially moved to GitHub
On 20 May 2014 at 14:11, jus...@postgresql.org wrote: > http://sqlitebrowser.org > https://github.com/sqlitebrowser/sqlitebrowser Sorry, should have said I'm on OS X Mavericks 10.9.3. -- Cheers -- Tim ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite Database Browser officially moved to GitHub
On 20 May 2014 at 14:11, jus...@postgresql.org wrote:
> Hi all,
>
> Just a small heads up. The old SQLite Database
> Browser project on SourceForge is officially
> on GitHub as of today, and we've made a new
> release (v3.1) as well. New website too (using
> GitHub pages):
>
> http://sqlitebrowser.org
> https://github.com/sqlitebrowser/sqlitebrowser
I followed the instructions at the github URL, and was able to build
sqlitebrowser. Couple of points:
1) Warn folks not to have a single-quote (') in their path, it causes the make
of sqlitebrowser to fail. I moved the folder elsewhere and redid the qmake,
make, steps and it completed.
2) It took 57 minutes on a 2011 2.3GHz Core i5 Mini to build qt (whatever that
may be) although perhaps a bit of that might have been it waiting for me to
agree the licence (I was out of the room). That wound the CPU up to 400%, the
fan to 6000rpm, and the core temp to 90C. Still, it seems fine.
I also had to install brew, but that was quite quick.
Now I'll have to figure out how to use it.
--
Cheers -- Tim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Pre-preparing querys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/05/14 21:09, James K. Lowden wrote: > I took "statement cache" to mean that execution plans would persist > either past sqlite3_exec() or that many plan would be kept, in case > later useful, when sqlite3_step() recompiles according to passed > parameters. I think that's unlikely to help much, and might hurt. Statement cache means something front-ending sqlite3_prepare. A simple implementation would be updating sqlite3_finalize to stash the statement in a (bounded) hash table keyed by the SQL. Then in sqlite3_prepare look in the hash table for the SQL and return the stashed statement on match. (There are a few more subtleties.) > You're talking about using one prepared statement repeatedly, which, > if nothing else, is convenient. Statement cache sizes seem to be between 10 and 100 entries in various implementations I looked at. > And the application can always maintain its "cache" of > prepared-statement handles. Ah, for the olden days :-) Where exactly would this cache live? What if you are using several different libraries and modules that don't know about each other? What about various ORMs? The olden days where the app developer is responsible for every line of code in the app and they all work together well, including cooperating over a SQLite statement cache are a rarity now. Ask these questions: - - Should app/library developers using SQLite have to implement their own caching mechanism? - - Why did the majority of developers writing wrappers for SQLite spend the extra effort to also implement caches? BTW my answer for the second one is because statement preparation showed up in profiling, both outside and inside SQLite. The outside bit was because of having to do UTF8 conversion from native string representation, and inside because statement preparation takes a while - it involves parsing, many memory allocations and lots of other fiddly stuff. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlN7rRMACgkQmOOfHg372QRVoQCgtNdWJ/LiD67W2O7sdVSGinbV mvQAniz4mbJr3+8pzYj0siG5v+jjj+Ko =SB5Q -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite Database Browser officially moved to GitHub
On 2014-05-20 16:35, big stone wrote: Hi Justin, What are the necessary steps to rebuild SQLite Database Browser from source, on a windows 7 PC ? (I have no Qt experience, so not sure of what to download ) Good question. We should write up some instructions for that. :) Rene or Martin (both CC'd) are the C++ guys, so may be able to help. I *think* Rene is generating the Windows binaries by cross compiling from Linux. The binaries seem to work pretty well, so (thus far) it's been an ok approach. ;) I tried quickly myself about 2 weeks ago, but wasn't sure which bits of what to download (eg msys? mingwin? sqlite-libs?) so didn't have any success. Kept with OSX Homebrew instead at the time. ;) Anyway, hopefully Rene or Martin can help. :) Regards and best wishes, Justin Clift ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite Database Browser officially moved to GitHub
Hi Justin, What are the necessary steps to rebuild SQLite Database Browser from source, on a windows 7 PC ? (I have no Qt experience, so not sure of what to download ) Regards, ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite Database Browser officially moved to GitHub
Hi all, Just a small heads up. The old SQLite Database Browser project on SourceForge is officially on GitHub as of today, and we've made a new release (v3.1) as well. New website too (using GitHub pages): http://sqlitebrowser.org https://github.com/sqlitebrowser/sqlitebrowser Hope that's useful for people. :) Regards and best wishes, Justin Clift ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Usign sqlite as user authentication JDBC Realm in tomcat 7
Dear all, I would like to know if it would be possible to use sqlite3 as db with JDBC Realm authentication in tomcat 7. If so, any configuration example would be really welcomed. I have found contradictory information on the net (web sites where people say that it can be done and web sites where others state that it can not be done). Unfortunatelly examples are also usually really incomplete (like "put this code in server.xml" without stating where in the file to add that code). Thanks in advance, ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Pre-preparing querys
On 05/20/2014 07:30 AM, James K. Lowden wrote: On Mon, 19 May 2014 22:26:29 +0100 Simon Slavin wrote: On 19 May 2014, at 10:21pm, Roger Binns wrote: It seems like most language wrappers for SQLite include some sort of statement cache because it is generally useful. It seems like the sort of thing that would be helpful within the core of SQLite itself, or as an officially supported extra extension. Are there any advantages to this other than increased speed ? I'm going to go out on a limb and say No, and moreover it's not obvious there would be any improvement. Do we have statistics on the query planner's performance? How much improvement could the user (reasonably) hope for? I would expect the answer to be Not Much. On a modern computer I/O dominates everything, including SQL parsing. I expect that's true on many (all?) systems, but not all queries cause any actual I/O. Often the entire database sits in the OS cache or SQLite pager cache, so querying the database just means shuffling bytes around in main memory. I vaguely recall that at one point for the simplest possible queries: SELECT * FROM t1 WHERE rowid = ? if the database is in already memory the prepare() and step() calls are roughly similar in terms of real time. And most of that is the implicit transaction - executed within a BEGIN/COMMIT block the prepare() step is much more expensive than the step(). I'm not sure about more complicated queries. But I suspect it's very easy to find cases where the prepare() is at least as heavy as the step(). Dan. In theory very complex queries would be the exception, except that query planners long ago developed heuristic shortcuts. Mathematically, an N-way join is a combanatorial problem with N! solutions. When N is, say, 8, that's a lot to consider, 40,320 alternatives. A shortcut in such a case becomes the only cut. Even the perfect plan, by the way, may not be worth preserving. As the developers know, No battle plan survives first contact with the enemy. --Helmuth von Moltke meaning that any query plan, no matter how fine, is based only on the state of the data at the time. Change the data enough and it becomes slow, or useless. That's just an outline of the general case. I'll be interested to see what we know about SQLite's in particular. --jkl ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
