Adding tables from a plugin start.php

Is there a clean way to get a plugin to add new tables it needs? Does Elgg provide a function to read an SQL file with the db prefix abstracted out?

  • there I go again, answering my own questions!

    run_sql_script()

  • There is no "clean way" to add tables to Elgg as the API expects that the core table structure is all you need.

    Low level database functions like run_sql_script() are not part of the API but are for internal purposes only.

    Adding tables means essentially forking the code, making it difficult or impossible to upgrade, etc.

    Are you really sure that you need to do that?

  • Yes I need to do that and no, it's not forking the code! It's adding a couple of tables to support the plugin. Why would it be difficult to upgrade? Does Elgg remove non core tables? The tables are specific to the plugin and only the plugin knows about them.

  • @Brane,

    You're not "forking" code lolz ;-) simply re-using the php code.

    I do not believe Elgg would "tamper" with any other tables at upgrade-time. I'm sure if you check thru the "upgrade" code - it should be only doing elgg-specific upgrades to elgg *core tables

    The code in run_sql_script() looks pretty standard well written code to do what I believe you wanted to do in the first place ==> fetch the tables' elgg prefix text so that your plugins would then also use that --> "standardization" ;-)

    We have other non-elgg plugins in the same database where we have integrated that plugin into our elgg site...;-)

  • The difference between class metadata and attributes was a bit confusing at the start and I wasn't sure if Elgg could persist attributes that were arrays, so I went down the tables route. In the end, I didn't need to persist arrays but just kept the tables anyway. I could prolly change it to use attributes instead but if tables are safe, what the heck!

  • Elgg automatically manages a lot of data for you and may do more of that in the future. If you add tables that core Elgg does not know about, you are simply asking for trouble in my view.

    There is no way that I would ever recommend that approach to one of my clients.

  • I do not agree.

    There are many existing PlugIns for Elgg which have their own databses, tables, etc, some examples being Vanilla Forum ( 1200+ downloads) which was integrated for Elgg without forcing Vanilla to drop it's own databases, PhpBB3 ( 500+ downloads) PlugIn the same, 123Chat the same, VBulletin the same, Moodle the same..;-) 

    I would not be the one to tell those Elgg Users nor the Authors of those PlugIns that they are asking for trouble and so should drop those PlugIns and look for a different solution ;-)

  • Dhrup,

    There is a huge difference between integrating other apps (which of course, have their own tables, usually in a separate database) and adding Elgg-specific tables. Elgg specific tables undermine one of the major points of the Elgg API, which is that Elgg handles your data for you.

  • Indeed, for integration new functionality we use Elgg API only.  For coupling - often meaning duplication of some info, we use separate installs with unavoidably own tables. If Plugins do make their own tables in Elgg database, it should be clearly specified upfront! I don't want any plugin to mess with the table structure, unless I am 100% sure the API could not be used...

  • If that's the case, why does Elgg have a table prefix? Why would core want to trash tables it knows nothing about? That's the impression I'm getting from this conversation, well that's what I gather from "asking for trouble".

    As for Elgg handling my data for me, I went down the table route as there's no documentation on that feature and I discovered what Elgg actually does with my data. When I delete a class, first its metadata is deleted, then the dead class is reloaded multiple times, with no access to its metadata, which is gone. That's a side effect of the Elgg "ORM" architecture. Normally in OO situations, classes should be "first class citizens", i.e. when they are loaded they should be ready for use. That's not the case with Elgg. During deletion, a class is slowly eroded rather than deleted in a one pass operation.

    Elgg can prolly handle most data persistence situations but I don't think adding plugin specific tables should be a problem. Note that I said plugin specific tables. I could see your point if I'd extended core and added tables the extension needed. To me, that's what you mean by elgg specific tables. I'm using plugin specific tables. Completely different thing.

    Thanks for the feedback though, most interesting!