Home » Archived » BIRT » Data Access Issues
| Data Access Issues [message #172] |
Fri, 19 November 2004 19:47  |
 Mike Fox
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
I have just read the recently posted Release 1 requirements. I am
particularly interested in the available data sources for reports. The
document doesn't deal with this topic in any depth, and only briefly lists
JDBC and Custom (which can be used to get data from java objects).
Is there more information on this available? Will java objects acting as a
datasource have to implement a known interface, possibly
java.sql.ResultSet or something like it?
I am currently designing a J2EE/Servlet based reporting solution that must
efficiently deliver data via java objects. These objects must be
dynamically created and loaded with data during the report generation
process, and be passed to BIRT via its API. I need this because data can
come from a variety of sources:
- A database, but with several layers of software on top of it to handle
queries and transformations. Users can construct queries but can never see
SQL. They will use field names that are different from the DB table column
names.
- Java code specific to an individual report to manipulate data beyond the
scope of a query or report script
- Data that was never in a relational db. It may have been extracted from
an EMF model, for example.
- Will it be possible to stream data in XML?
- It is important to use memory efficiently as datasets can be large.
While doing a project at a previous company, we frequently ran out of
memory because the reporting system API forced us to have two copies of
the entire dataset in memory.
- When designing your API, I'd much rather supply an iterator than a
collection. That way its possible to generate the data as you request it,
rather than having to build it all first.
All reporting systems I've seen can obtain data via JDBC, but I've had a
problems here in the past. Generally they require a user account and
password to create a connection. This is problematic, as the system
generally doesn't want to distribute that information for security
reasons. Also, it is undesirable if the system utilizes connection
pooling. It would be much more convienent if I could pass BIRT a JDBC
Connection object to use via its API.
Hope this helps, and please contact me if you want to followup.
Mike Fox
IBM
foxm@us.ibm.com
|
|
|
| Re: Data Access Issues [message #183 is a reply to message #172] |
Mon, 22 November 2004 13:45  |
Eclipse User |
|
|
|
Originally posted by: bonacinig.ausl.re.it
Mike pointed out many right issues, but i think that the most important one
it's the capacity to work with large datasets without loading them all in
memory.
I've seen many reporting tools and the vast majority doesn't handle this
problem, that occurs VERY FREQUENTLY in real world reporting scenarios.
So i hope BIRT will address this issue and solve it in some way (using
temporary files or other techniques).
Giovanni Bonacini
"Mike Fox" <foxm@us.ibm.com> ha scritto nel messaggio
news:cnlik3$t7e$1@www.eclipse.org...
> I have just read the recently posted Release 1 requirements. I am
> particularly interested in the available data sources for reports. The
> document doesn't deal with this topic in any depth, and only briefly lists
> JDBC and Custom (which can be used to get data from java objects).
>
> Is there more information on this available? Will java objects acting as a
> datasource have to implement a known interface, possibly
> java.sql.ResultSet or something like it?
>
> I am currently designing a J2EE/Servlet based reporting solution that must
> efficiently deliver data via java objects. These objects must be
> dynamically created and loaded with data during the report generation
> process, and be passed to BIRT via its API. I need this because data can
> come from a variety of sources:
> - A database, but with several layers of software on top of it to handle
> queries and transformations. Users can construct queries but can never see
> SQL. They will use field names that are different from the DB table column
> names.
> - Java code specific to an individual report to manipulate data beyond the
> scope of a query or report script
> - Data that was never in a relational db. It may have been extracted from
> an EMF model, for example.
> - Will it be possible to stream data in XML?
> - It is important to use memory efficiently as datasets can be large.
> While doing a project at a previous company, we frequently ran out of
> memory because the reporting system API forced us to have two copies of
> the entire dataset in memory.
> - When designing your API, I'd much rather supply an iterator than a
> collection. That way its possible to generate the data as you request it,
> rather than having to build it all first.
>
> All reporting systems I've seen can obtain data via JDBC, but I've had a
> problems here in the past. Generally they require a user account and
> password to create a connection. This is problematic, as the system
> generally doesn't want to distribute that information for security
> reasons. Also, it is undesirable if the system utilizes connection
> pooling. It would be much more convienent if I could pass BIRT a JDBC
> Connection object to use via its API.
>
> Hope this helps, and please contact me if you want to followup.
>
> Mike Fox
> IBM
> foxm@us.ibm.com
>
>
|
|
|
| Re: Data Access Issues [message #262 is a reply to message #172] |
Sat, 04 December 2004 22:50 |
Linda Chan
Messages: 845
Registered: July 2009 |
Senior Member |
|
|
Hi Mike,
Thanks for your input.
We are currently working on the specifics of the extensions for custom data
sources, which will be published when details are available. Your input are
much appreciated.
In general, Java objects acting as a custom data source would indeed implement
the BIRT runtime data access interfaces. This interface is similar to JDBC,
and it supports additional capabilities such as any types of data source, the
use of data source specific query text ( i.e. not SQL specific), complex
parameters, etc.
Its ResultSet-like interface with a next method would be like an iterator,
which your implementation could control and optimize the data generation or
retrieval.
Regards,
Linda
Actuate Corporation
Mike Fox wrote:
> I have just read the recently posted Release 1 requirements. I am
> particularly interested in the available data sources for reports. The
> document doesn't deal with this topic in any depth, and only briefly lists
> JDBC and Custom (which can be used to get data from java objects).
>
> Is there more information on this available? Will java objects acting as a
> datasource have to implement a known interface, possibly
> java.sql.ResultSet or something like it?
>
> I am currently designing a J2EE/Servlet based reporting solution that must
> efficiently deliver data via java objects. These objects must be
> dynamically created and loaded with data during the report generation
> process, and be passed to BIRT via its API. I need this because data can
> come from a variety of sources:
> - A database, but with several layers of software on top of it to handle
> queries and transformations. Users can construct queries but can never see
> SQL. They will use field names that are different from the DB table column
> names.
> - Java code specific to an individual report to manipulate data beyond the
> scope of a query or report script
> - Data that was never in a relational db. It may have been extracted from
> an EMF model, for example.
> - Will it be possible to stream data in XML?
> - It is important to use memory efficiently as datasets can be large.
> While doing a project at a previous company, we frequently ran out of
> memory because the reporting system API forced us to have two copies of
> the entire dataset in memory.
> - When designing your API, I'd much rather supply an iterator than a
> collection. That way its possible to generate the data as you request it,
> rather than having to build it all first.
>
> All reporting systems I've seen can obtain data via JDBC, but I've had a
> problems here in the past. Generally they require a user account and
> password to create a connection. This is problematic, as the system
> generally doesn't want to distribute that information for security
> reasons. Also, it is undesirable if the system utilizes connection
> pooling. It would be much more convienent if I could pass BIRT a JDBC
> Connection object to use via its API.
>
> Hope this helps, and please contact me if you want to followup.
>
> Mike Fox
> IBM
> foxm@us.ibm.com
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 15:07:47 GMT 2024
Powered by FUDForum. Page generated in 0.03392 seconds |
] 
Search
Help
Register
Login
Home
