RSS Feed

Plugin Developer Discussion

The abstraction of trying to add the plugin prefix behind the scenes is too leaky.

The problem is that the API tries to add the prefix automatically, but there are way too many places where the prefix is not automatically added. The result is that half the time I am using the wrong table name, but I don't know until I test it and it crashes.

I think the easiest solution on everyone is to change the code that automatically adds the prefix, when a prefixed is expected, to throw an exception if the prefix is missing. This way as a plugin developer, I can just always add the prefix, since a plugin developer has to learn about table prefixes if he does anything beyond a very simple plugin.

Hi Stefan, can you provide an example of inconsistency that caused you trouble? The plugin prefix is definitely necessary to avoid name collisions, and PluginTableName() is provided as a convenience, but we're open to alternative approaches.

I think the prefix approach is fine. The problem is the code that adds this prefix automatically, instead of requiring that I do it myself.

I have to add my vote to this to agree with Stefan that this abstraction is leaky.  I opened a case about fixing the docs (which were fixed) but something about it bothered me a bit still.  What Stefan is suggesting if I'm correct is just that in the places where we don't want the devs to post the prefix, we allow them to do it anyway and notice that on the backend (and deal with it).  That way as a dev, we can ALWAYS add the prefix and not worry if we're doing something wrong.  Is that right Stefan?

Yes, several times this has bit me.

I would suggest going one step farther. I don' think the API should ever call PluginTableName(). In cases where it does currently. It should throw an exception. Then the API would be completely consistent. If you aren't referring to an actual FB table, then you must prefix the table name.

I've opened a case for this.  I think Stefan is right -- the only consistent solution is to throw an exception even for methods like

api.Database.NewTable("MyTable")

so that developers learn early to always prefix their tables, so they don't get bit in the places where we can't throw an exception, like

querySelect.AddSelect("MyTable.ixFoo")

This change was included in 7.0.2a, by the way.  Tables are no longer implicitly prefixed.

IPluginDatabase.BugJoinTables still appear to allow non prefixed table names to be returned.

Actually, it did complain just not where I expected. If the plugin doesn't return valid schema, I would expect the plugin to be disabled and have a "load error" similar to when the api version numbers don't match.

I've opened a case for this.  Right now when an interface method fails, we try to keep going, but you're probably right that if the schema fails we should give up.