Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

Vanilla with flatfiles

edited November 2005 in Vanilla 1.0 Help
Pretty random, but i was thinking about the scalability thread, and although i have no desire to do this, roughly how difficult would it be to move vanilla onto using flatfiles? And would this show any worthwhile performance gains? Just curious...

Comments

  • Options
    At the very least it would let those who don't have access to a DB use Vanilla.
  • Options
    Are there lots of people whose hosting services support PHP, but not MySQL?
  • Options
    There are a not insignificant number of companies who provide php as standard but charge for databases. Not many, but they are there. I considered that as a use for a flatfile method but realistically a database would still be much simpler for certain things (i think, anyway, i havent put much thought into it). I was thinking more from a performance viewpoint and mainly just for interest.
  • Options
    Most free web servers do not have databases (that I know of), and maybe some people that host a small site off their PC. A flatfile option would be used by a few I think,
  • Options
    edited November 2005
    Does 0.9.3 separate DB access into a separate extension? This could make it easier to write PostgreSQL and SQL Server extensions too.
  • Options
    MarkMark Vanilla Staff
    edited November 2005
    bergamot - the database is accessed through two classes: SqlBuilder and MySQL. the MySQL class is an implementation of the Database interface. Which means that you can pretty easily go and write a PostgreSQL class that follows the same interface. Then you'd just need to tell the object factory to use the PostgreSQL class instead of the MySQL class and you've got a postgre port. Of course there are going to be issues with regard to the variations between sql syntax in mysql and postgre. This can be resolved by writing a new version of the SqlBuilder class that is specific to postgre. The only problem that remains is that all of the sql, even though it is built with the SqlBuilder class, is declared in the vanilla-specific data objects. So, doing something like, say, using a postgre stored procedure to select data instead of using the currently defined sql select statement (as defined in a vanilla object, and passed through the sqlbuilder object to the database object) is just not do-able. I have been trying to think of a way to change this. Maybe to have a single central file that contains all queries used by vanilla - which would allow you to make changes or completely replace that file as you want to port to different applications. But that's a hell of a lot of work, and I can see problems coming from that as well. I haven't thought of a really solid way of doing it yet - so it will be remaining as is for version 1. As always, I'm open to new ideas if anyone has any.
  • Options
    To be honest, I don't blame you; hacking a middle tier into an existing app is not an easy task, and it's usually a long time before any visible payoffs are realized. I was mainly just wondering if it had already been done, in which case it would be silly to worry about how best to go about it.
  • Options
    lechlech Chicagoland
    I can't remember it's name, but I do recall a series of classes that mimiced SQL except it wrote out data to flatfiles. It could be on pear by now.
  • Options
    Your probably thinking of txtSQL.
  • Options
    lechlech Chicagoland
    yep, that's it, I remembered all the details, just couldn't remember it's name.
This discussion has been closed.