Plugin Developer DiscussionDiscussion for FogBugz Plugin developers |
||
I am trying to write a query that joins a custom plug-in table to the BugEvent table, but prefer not to hardcode a reference to the "BugEvent" table in my Query.AddInnerJoin call.
Is there a way through the API similar to api.Database.PluginTableName() that I could use to "future proof" my implementation a bit with regard to referencing standard FB table names?
This is not exposed currently. I'll open a case for the entity classes to expose constants with their table names, but it probably won't make it in for 7. For now, I'd suggest you define your own constants and then if we did change anything you'd just have to change that one constant value.
When I use this approach it throws this exxeption
"FogCreek.FogBugz.Exception.FogBugzSecurityException: This query is unsafe because it references one or more FogBugz tables. To run this query, set IgnorePermissions to true." The ignorepermissions setting solves it, but I feel like perhaps I am going at this wrong. For example, would I be better off using the CBugEventQuery class somehow instead of trying to join to the table directly with a regular CSelectQuery class? I couldn't find any examples or class factories for CBugEventQuery so I wasn't sure how to use it (or what it would be used for)
The C*Entity*Query classes are special subclasses of CSelectQuery that return arrays of entity objects (for example, CBugEventQuery returns CBugEvents) and enforce some permissions of the current user
Using GetDataSet on a CSelectQuery requires IgnorePermissions to be set because you're working with a raw dataset and no permissions are being enforced. If you tell me a bit more about what you're trying to do, I can try to steer you down the right path. In general, if you set IgnorePermissions you should be checking permissions yourself to make sure you don't expose anything that the current user doesn't have permission to see.
Here is the simplified version of what I am trying to do.
I created an custom table with a 1-1 relationship with the BugEvent table to store additional properties associated with a particular Bug Event entry. What I am trying to do is query all of the entries in my custom table associated with a particular Bug that the event is associated with, which requires joining to the BugEvent table so I can filter on BugEvent.ixBug in my where clause. As I've said. I've made this work just find by hardcoding the BugEvent table and turning on ignore permissions. I was just wondering if there was a more standard approach. No big deal if there isn't.
That sounds fine, as long as you are checking the permissions on the Bug. You could use CBugEventQuery and join your table to that if you're listing bug events and want to also add your information, but if you're just listing your column then what you did seems fine.
One performance tip: make sure you have an index on the column you are joining to BugEvent. BugEvent is usually the biggest table in FogBugz and can be a real performance killer if you're not careful.
That actuall brings me back to my previous question, how do you instantiate an object from the CBugEventQuery? I don't see a class factory and it doesn't seem to have a public constructor.
Thanks for the tip on indexing the column. I hadn't realized the API exposed that ability until you mentioned it. While we are on the subject, do I need to separately add an index to columns created with CTABLE.AddAutoIncrementPrimaryKey or are indexes created automatically on those columns?
Ah, sorry, I misunderstood your earlier question. In general, if a class is public but the constructor is private then it must be instantiated through the API. For CBugEventQuery, you can instatiate it through the BugEvent API:
api.BugEvent.NewBugEventQuery() Also, primary keys are automatically indexed so you do not need to add an index for them. |
Powered by FogBugz