Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Fatal Error on Import

edited October 2009 in Vanilla 2.0 - 2.8
I'm trying to upgrade from 1 to 2. I'm getting the following error:

Fatal error: Class 'DatabaseStructure' not found in /home/ben/ on line 31

I've tried the both the "Dev" and master version. Is there something I'm doing wrong?


  • Options
    Ok, I've gotten past this (BTW, you have two errors in step 11 of the import process - two tables have been lowercased in your code making it so it can't find the tables).

    Everything is imported, however, only NEW (post import) comments can be searched, is there anything I can do about this?
  • Options
    LincLinc Detroit Admin
    @tazz_ben That table casing error was previously reported in an open bug ticket. I made a quick edit and did a pull request so hopefully it'll be corrected in main soon.

    I assume the old imported comments haven't been indexed in the search tables. I don't know if a "re-index my forum" option exists anywhere; it probably should to cover imports or else every importer will need a search indexer.
  • Options
    Thanks @Lincoln, I still haven't spent the time to learn Git, I probably should do that so that I can post to projects like this.

    Yeah, I looked at the search tables and you are right, it looks like it hasn't indexed and of the old posts. Do you happen to know where in the code I can look at how the indexing works, so that hopefully I can write a simple reindex tool.

    (Just as a side question, what was the reasoning for this DB design. It seems as though all that was done was create a manual version of what a MySQL fulltext index would do. And, if there is something special, why wasn't it done with a MySQL trigger. That way the developers wouldn't have to worry about indexing implications every time they insert or update a comment)
  • Options
    LincLinc Detroit Admin
    @tazz_ben Haven't found the indexing code yet, sorry.

    I assume the keyword search is for databases that lack fulltext, though I'm not sure that's a good reason for the ridiculous amount of overhead it can create. Probably a topic for another discussion.
  • Options
    ToddTodd Chief Product Officer Vanilla Staff
    Yeah the keyword search is something we are trying as a baseline. It's meant to be pluggable though.
  • Options
    So, maybe this should be in a new thread, but I'm still a bit confused on the reasoning here @Todd. From even the relatively limited number of posts sense the upgrade, there is now a huge number of words. And it isn't stored as efficiently as a fulltext index. Additionally it seems to store stop words like "has", "when", etc. If the reasoning is that you want to be able to support mysql installs without fulltext indexes enabled; the only scenario I can think of is that the person has it installed on a shared host (given boolean operations have been supported sense MySQL 4.1). If that is the case, their going to also run into performance problems from this design.

    Sorry, to be so blunt, but I'm the author of Heap CRM and Torch Project Management, so I spend a lot of my time trying to figure out more efficient ways of executing complex mysql searches, and well this struck me as extremely inefficient.
  • Options
    ToddTodd Chief Product Officer Vanilla Staff
    edited October 2009
    Hey @tazz_ben no need to apologize, I seriously appreciate the comments. I can make an object that uses mysql full text. One thing is that you can only do a query on a single table while the search we do needs to be able to combine the search of the topic and comments. Any ideas on this?

    Maybe I've just been prejudiced here. I've had bad experiences with full-text queries in the past, but I'm willing to give them a go now.
  • Options
    Not knowing the exact structure where stuff is stored I can't be sure, but in general it is almost always better to use a mysql union. MySQL executes each part of the union independently of each other then merges the results, which means you can use two independent indexes (in this case full text indexes).

    I'd recommend you use the full text index in boolean mode. What you can do then is explode the search term and plop a "*" at the end of each word. That way it matches variations of words (is this what you are talking about with bad experience?)

    No matter what you do, run explain on it to make sure it is executing the way you expect.

    If you want you can provide the final query or whatever, I can provide some advice on how it might be executed faster by changing it a bit or changing the indexes (for whatever that's worth).
Sign In or Register to comment.