[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mifos-developer
Subject:    Re: [Mifos-developer] On Data Extracts and Reports
From:       "Van Mittal-Henkle" <vanmh1 () comcast ! net>
Date:       2007-03-21 22:09:07
Message-ID: 003501c76c05$91938930$2101a8c0 () sunrise
[Download RAW message or body]

> So if we're that far, why work so hard to filter out unneeded fields,
> etc.? If we're already providing an import format, which SHOULD be
> kind of complete, or complete enough, use it for export as well, and
> just dump EVERYTHING, packaged loosely around objects that make
> sense. Don't even try to digest it for operational purposes like
> reporting.     

Although the scope of the initial data migration work only includes the import
part of this, I am going ahead with a design that will support export.  

I will note that the initial use case for this would be to provide a set of
java classes which a Mifos specialist could use to put data into objects and
then dump them in the Mifos Data Exchange XML format.  This would relieve the
Mifos specialist of having to write XML related code or having as detailed an
understanding of the schema as they might otherwise need.

The upshot is that the schema will be one and the same for import and export.
 
> The downstream ETL into a reporting store that might then be employed
> could come from any of a wide range of free and for-pay tools, all of
> which are mature and configurable to a wide range of needs; it's
> well-understood. So Jasper, and BIRT are nice. Could they in fact run
> against a separate reporting store? That reporting store may or may
> not resemble the core database. If we were to have a good
> import/export format, I don't think it would matter. Our reporting
> folks would then be free to design a reference db implementation for
> reporting that's actually reasonable for a less-experienced reports
> developer to use.         

The idea of using an export capability to load data into a separate reporting
store is interesting.  I don't know how practical it is from a tool or
performace perspective.
 
> Maybe let's first see how the import/export XML looks. Do we think
> it's really going to look a lot like a collection of objects that
> reflect the domain model, or are we looking at something that's more
> like a reporting markup? Perhaps I'm not being too terribly clear
> with that question?    

This first phase of the project will produce relativly simple XML for the
single Center business object, so there may not be much to go on initially.
I'll post some XML and the intial schema when they are a little more complete
than they are now.

--Van




[prev in list] [next in list] [prev in thread] [next in thread]