Bugzilla – Full Text Bug Listing
| Summary: | ROM API very slow in read only situations | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mike Boyersmith <mjboyers> |
| Component: | BIRT | Assignee: | Xuelan Li <xuelan.li> |
| Status: | VERIFIED FIXED | QA Contact: | Tianli Zhang <tzhang> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | clin, rlu, wenfeng.fwd |
| Version: | 2.1.0 | Keywords: | plan |
| Target Milestone: | 2.5.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
The fields that we currently would like to see ROM fast access to include Display name Description However, I could see value in having quick access to all the General, description, and comments properties fields such as created by author comments as additional examples A couple of suggestions on how to speed up DE API for read access to report-level properties: (1) Delay the instantiation of ROM objects for various report elements until they are actually needed. Upon opening the report design, perhaps only the report design element and its properties are read. (2) (Not sure if this helps) Introduce a read-only mode to eliminate any transaction related costs. ROM needs to do inheritance calculations for some properties, such as the color or font of a text report item, which require creating the object hierarchy as well as searching libraries. Maybe we shall start with profiling the overhead of loading a report design and the time it takes get report element properties both simple properties (description and display name) and more compplex properties that require inheritance resolution, and based on the profiling result to decide what change could be made. Now, Model can support the read-only of report properties. That is, call openDesign( String fileName, ModuleOption options) -- set 'read-only' config in the options. Then the returned ReportDesignHandle will read all the report properties, such as name, display name, comments and so on. However, all the report layout details will not be loaded, such as the data sets, data sources, and style, body layout elements defined in the report. Does this meet your requirements?(In reply to comment #1) > The fields that we currently would like to see ROM fast access to include > > Display name > Description > > However, I could see value in having quick access to all the General, > description, and comments properties fields such as > > created by > author > comments > > as additional examples > This solution looks like it meets our needs, will talk o our group and see if there is anything else that might be nice to have fast cached, in a read only way. I think this fix is in the right direction. Definately speeding up reading is helpful and solves this RFE. After talking with the team, we would alo like to be able to "write" changes to properties quickly as well. so fast read and write of properties would be ultimately ideal. Should I file a new RFE, of is it possible to do writes with this change as well, quickly? Can you give me a clear requirement about this bug? 1) You want to get/set properties for report design only. We need not parse the whole design tree but just to read the properties set in report design. right? 2) When writing the design out to file, we still need not to write the design contents, such as data sources, data sets, and styles. Only write the properties set in report design out. right? If these two will meet you demands, maybe, we can provide such APIs. What are the config options for parsing a report design? Suggest to have an DE API spec for all these options before adding new options. How about adding an FAQ entry on the Eclipse BIRT wiki site for DE API - "What are the API options for opening a report design file?" When saving a report design, we need to save the entire report XML files, instead of only saving the general properties, correct? Is the request to speed up saving the design file by saving the layout section of the XML string directly rather than serializing it from an internal data structure? Writing and reading of properties fast is what were currently looking for. For example, say I have a User interface that shows a list of reports in it that the user can select from and run. Now imagine you have 100 or even 500 reports in your UI. The UI fields in the UI might be author, display name, description, dates and other information... now fetching and writing this information so everything stays in sync with UI can be a massive hit. Granted caching can help some but... in general it would be nice to have optimizations for fast reading and writing of this information in a supported API. (In reply to comment #9) > Writing and reading of properties fast is what were currently looking for. > For example, say I have a User interface that shows a list of reports in it > that the user can select from and run. Now imagine you have 100 or even 500 > reports in your UI. The UI fields in the UI might be author, display name, > description, dates and other information... now fetching and writing this > information so everything stays in sync with UI can be a massive hit. Granted > caching can help some but... in general it would be nice to have optimizations > for fast reading and writing of this information in a supported API. Besides providing an ROM API option to only load root level properties of the report design, an alternative solution is to use an index file. Actuate has a commercial product that has some features in this area. It creates an index of report designs with common properties, such as report name, author, display name, description, dates. Also offer version control of the report design. I think we might want to consider similar concept in a project/index file. It would be much faster to read/write such an index file than open/close lots of files even if we only parse load a subset of that file. schedule to next release to add the load design option to load root level properties only, since we can not change the model API now. Is there suggestion how to speed up writting the root level properties only? I'm thinking the best way to handle fast root level reading and writing would be to have a light weight report adapter pattern or something like that that knows how to quickly read and write these properties with out loading all the birt plugins (huge hit). The key here is to have something very light weight that doesn't pull in the ROM or all of birt just to quickly read and write to a design. (In reply to comment #11) > I'm thinking the best way to handle fast root level reading and writing would > be to have a light weight report adapter pattern or something like that that > knows how to quickly read and write these properties with out loading all the > birt plugins (huge hit). The key here is to have something very light weight > that doesn't pull in the ROM or all of birt just to quickly read and write to a > design. There is a cost of loading the ROM schema metadata file, but it is only loaded once for each BIRT DE instance, the same DE can be used to read/write a lot of XML files. Do you start up/shutdown BIRT DE each time a report design file is read/write? DE = Data Engine, correct? (In reply to comment #13) > DE = Data Engine, correct? > Sorry. DE = Design Engine = the BIRT model component. Data Engine = DtE (data and transformation engine). schedule to 2.3.0 for further investigation and design.. It is possible to read/write string properties only for the report design/library and ignore other components such as data source, data sets and report items, etc. For contents that we want to ignore, read them as plain XML text and don't create corresponding report element instances. And for such designs, should also forbid user to add/remove and elements since all elements are invisible. If expect this change, please mark it as 2.3.1. Thanks. (In reply to comment #16) > It is possible to read/write string properties only for the report > design/library and ignore other components such as data source, data sets and > report items, etc. For contents that we want to ignore, read them as plain XML > text and don't create corresponding report element instances. And for such > designs, should also forbid user to add/remove and elements since all elements > are invisible. > If expect this change, please mark it as 2.3.1. Thanks. Do we need a new option on the open report API? (In reply to comment #17) > > Do we need a new option on the open report API? > Yes, the new option is needed. Suggest to make this change in 2.5.0 since the fundamental change in the design parser. Fixed. Add a key READ_ONLY_MODULE_PROPERTIES in ModuleOption. When calling openDesign/openLibrary, set this option to true; for example, openDesign(url, options). In Read-only module, we can get simple properties in report design, say, created by, displayName, author and etc, in this module operation like setting a property is forbidden. I compare the time when parsing a same report which has multiple tables, dataset, libraries and other properties. It really save the time when setting read-only to true. For this case, this fix fits for the need. But it is not flexible. We may have another enhancement, say, in read-only module, user can only get the simple properties, if he wants to get other properties like some properties of a known table, what should he do? Can we support a way for user to specify the property he wants to get? So for this bug mark as verified first and I think we should think about this enhancement. |
Using the ROM API to get details about a report design is very very slow. For instance the BIRT ROM API code to get a display name looks something like _url = url.getFile(); _designEngine = new DesignEngine(new DesignConfig()); _session = _designEngine.newSessionHandle(ULocale.getDefault()); _design = _session.openDesign(_url); String displayName = ""; //$NON-NLS-1$ try { displayName = _design.getDisplayName(); // there may not be a display name so return "" if (displayName == null) displayName = ""; //$NON-NLS-1$ } catch (Exception e) { e.printStackTrace(); displayName = ""; //$NON-NLS-1$ } ...... This is very slow for us... what we see is that the BIRT ROM seems to load the entire rptdesign into a model, which is very time expensive. One thing we have done for now, is written a 'light weight' class that opens the design and just quickly fetches the fields for us using simple DOM. Its way faster than using the ROM but not ideal as best code practices point out that you should use a published formal API for accessing data because custom code is often prone to breakage as data forms change over time. So we would like to see the ROM support a "fast" ROM mode, for read only access. of report attributes.