Discussion for FogBugz Plugin developers
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.
Friday, April 24, 2009
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.
Sunday, April 26, 2009
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.
Monday, April 27, 2009
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
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
IPluginDatabase.BugJoinTables still appear to allow non prefixed table names to be returned.
Sunday, May 17, 2009
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.
Sunday, May 17, 2009
This topic is archived. No further replies will be accepted.Other recent topics