I’ve been looking into how Jira implements the OfBiz enterprise framework and I’m confused about the data fetching process. The whole system seems really complex when you want to get basic information.
From what I can tell, when you want to show a list of tickets, the system first has to figure out what fields to display in the table. Then it goes and gets the actual data for each field. This seems like a lot of database calls for what should be simple.
I’m trying to understand how you would write the database queries to get all tickets. Getting one ticket seems straightforward, but getting a whole list looks complicated. Is it even possible to do this with a single SQL query using joins?
The flexibility is nice but the performance seems questionable for an enterprise system. Can someone explain how the SQL would actually work for retrieving multiple records?
the ofbiz thing in jira seems more than needed sometimes. yeah, u can do joins in single queries, but jira does bunch requests for security filters. the main slowdown isn’t about sql; it’s really all about user permission checks. each ticket goes thru validation, and optimizing that is tough.
OfBiz EntityEngine utilizes “delegators” as the primary interface for database operations. To retrieve multiple tickets, you would use GenericDelegator.findByCondition(), which can support complex joins within a single query if your entity definitions are properly configured. The framework separates the logical data models from the SQL, allowing you to define relationships within the entitymodel.xml files, thereby optimizing the queries. In Jira, the findListIteratorByCondition() method is typically employed for ticket retrieval, as it supports pagination while preventing memory overload. Joins can certainly be used, with the EntityCondition API facilitating the construction of intricate WHERE clauses, which the framework translates into appropriate JOIN statements. Often, performance challenges stem from poorly defined entity relationships or absent database indexes rather than the framework itself. We experienced significant performance enhancements by adjusting entity cache settings and incorporating foreign key indexes.
Had this exact problem when we moved from our old ticketing system to Jira. Your performance worries are legit, but there’s ways to fix it. OfBiz has “view entities” - basically pre-built joins that grab related data with fewer queries. For ticket lists, Jira uses these to pull core ticket data plus the usual display fields all at once. Here’s the key: it doesn’t load everything upfront, just what you need for that first view. The real slowdown usually comes from custom fields and permission checks, not basic data pulls. Proper database indexing was a game-changer for us. Jira also caches field configuration metadata, so repeat requests fly. You can write custom queries with the EntityEngine API for better bulk fetching if you know the entity relationships well enough.