- This topic is empty.
January 2, 2014 at 3:10 pm #159521
Yeah, like that.
I don’t see how performance would be any worse than the rest of Kirby’s file-based storage. If you kept the id (maybe other significant “search” data) in the filename, then finding the desired comments would be as easy as
glob. If you have multiple comments per file, it would be even faster.
An issue that I think could arise is how you would gather up all those comments if you need to move to a different CMS?
How would you gather up all the rest of your content?
(Honestly, I was surprised that Kirby uses this sort of format, rather than something like json. It does make it easier for humans to compose, though. Hey! That’s it: a script that can parse Kirby’s text file format into json, then decode them into key=>value pairs and insert into whatever DB you’re moving to.)
The toolkit is just a shortcut using classes …
dbclass looks to be ext/mysql -specific (a bit of a disappointment), so using it with SQLite (or PDO, or MySQLi, etc.) is out. You certainly could use other database implementations with Kirby, but you’d need to “roll your own.”
I love SQLite. It is a very different “flavor” of SQL, and takes getting used to, but there are some fantastic advantages. The main drawback is that it is not too widely available “in the wild.” Where it is available, I’ve found that the installed version varies quite a bit, and there are some big differences between versions.
Unfortunately, I’ve found it’s not worthwhile unless you know in advance that your environment is going to support it, which isn’t practical when you’re talking about publicly distributed projects.
I totally agree that a DB is a better choice. I just wasn’t aware of how “acceptable” Kirby considered it. Beyond that, if the “no-DB” aspect of Kirby is a major draw, I’d see that as an incentive to think twice before adding one (especially for a single, specific task).January 2, 2014 at 3:21 pm #159522
The db class looks to be ext/mysql -specific (a bit of a disappointment), so using it with SQLite (or PDO, or MySQLi, etc.) is out.
“The db class of the new toolkit for Kirby 2 is using PDO, so that old stuff is gone for good.” – Bastian
Edit: I just saw that Bastian put up a reference guide for the new Toolkit.
From the looks of the documentation on github, it appears you can specify a type for db::connect() such as SQLite. See here (line 15).January 2, 2014 at 3:51 pm #159524
“The db class of the new toolkit for Kirby 2 is using PDO, so that old stuff is gone for good.”
oh, cool! I was looking at the
dbclass in kirby/lib/kirby.php.January 2, 2014 at 3:58 pm #159525
The only downside is that there is no release date for the new toolkit however, the last blog article to mention Kirby 2 states that is what he has been working on. Hopefully it’s close but I think he started from scratch.January 2, 2014 at 7:59 pm #159537
The only downside is that there is no release date for the new toolkit … I think he started from scratch.
Certainly looks like he did. No comparison with the original version.
I’d say get the new version off github, write your code, then you can do a review and any needed adjustments when it’s officially released.January 3, 2014 at 3:45 am #159560
Hmm. I could do that but what if I release this before the new toolkit is out?
I’d rather go with what he has now and then update my code after he releases it. Or I could possible ask him to email developers to update to the new toolkit if their extensions, plugins, require a change.June 11, 2014 at 8:33 am #172427September 30, 2014 at 6:55 pm #185131September 30, 2014 at 7:12 pm #185133
@AlenAbdula Haha. Thanks. I was listening when it was live. I was actually the first question that Bastian answered.September 30, 2014 at 7:13 pm #185134AlenParticipant
V2 looks pretty interesting.September 30, 2014 at 7:20 pm #185135
- The forum ‘Other’ is closed to new topics and replies.