Hi David,
Is there a usable Rails adapter for KirbyBase? ACID transactions (for DB
schema changes if nothing else)?
http://rubyforge.org/projects/ackbar - about to be released this weekend 
And with the good and bad of it, SQL is -the- standard RDBMS query language,
so that would restrict KirbyBase to small / personal projects where you're
sure you'll never change DB backends.
Also, why would someone that already knows SQL choose KirbyBase over SQLite?
The latter installs very easily too.
Sometime that is excatly why you need it: small, personal projects...
which are shrink wrapped to distribute to other users. For me that is
exactly what I need. A no hussle installation which works across
multiple platforms ('gem install app' which picks up the dbms).
No, it's not ACID. No, it doesn't support AR 100%. Yes, I will have
overhead to make sure my app works both on KB and on SQLite. But for
the end user who couldn't care less about the backend as long as it
works - the no third party to install works great. The plain-text data
format is also great - your data is always available to you, even if
my app or the database suddenly become problematic.
Of course, any *real* webapp might need need a *real* database. I'm
just talking about the less real, "works for me" class of applications
HTH,
Assaph
Dňa Štvrtok 09 Február 2006 23:26 Logan Capaldo napísal:
> And with the good and bad of it, SQL is -the- standard RDBMS query
> language,
> so that would restrict KirbyBase to small / personal projects where
> you're
> sure you'll never change DB backends.
Not true, KirbyBases' format is easily parseable and editable by hand
as well. It also accessible from Python.
I said switching DB -backends-, not what I access it with. I can to some
extent drop one SQL DBMS in place of another without changing the code
accessing it. I can't for example use KB to prototype an application and then
switch over to Postgres for scalability without rewriting my DB query code.
This is of course not an issue when using an ORM layer, and use of SQL doesn't
quite save you from having to do DB migration - even if dumping the schema
and data as SQL statements might help. Sounds like a potentially useful
feature for KB, is it already present? If not, it sounds arguably somewhat
easier to implement than a KB query-to-SQL compiler.
> Also, why would someone that already knows SQL choose KirbyBase
> over SQLite?
> The latter installs very easily too.
Well kirbybase is precisely 1 file of ruby sourcecode. Doesn't get
much easier than that, especially if you need to deploy elsewhere.
SQLite is one DLL, and one gem installation. I've walked managers through
that. More complicated, yes, but I can't imagine a deployment scenario where
on would pose significantly more problems than the other. Well, except
atomically packaging the application as a gem.
David Vallner
···
On Feb 9, 2006, at 5:01 PM, David Vallner wrote:
Dňa Piatok 10 Február 2006 00:08 Assaph Mehr napísal:
Of course, any *real* webapp might need need a *real* database. I'm
just talking about the less real, "works for me" class of applications
Well, that's the main problem with concurrency bugs. You don't know where they
might occur (e.g. they might theoretically occur anywhere) until they do, and
they're usually also very obscure bugs. The other way I had to SSH over to a
friend and do the SQLite delete column hack, and I was damn glad to have the
table locked while doing it and ROLLBACK at my fingertips - ever so slightly
a more elegant solution than taking the whole application offline and then
hacking at the file. Although very possibly subject to taste and the desire
to do things "right" for acquired meanings of the world more than anything
else.
Of course, for "works for me", it's probably Very Good (tm), as well as for
people that don't know SQL or find it excruciatingly painful to work with the
language or SQL shells.
David Vallner