Re: All Share Accounts

[Nayan Ambali]

Terence,

For this use case buildig report is better solution than getting this list
directly from API.

But I agree with you that there should be a API for /shares that returns
the collection of shares with sensible filters and limits.

Thanks
Nayan Ambali


On Sat, May 14, 2016, 3:43 PM Terence Monteiro 
wrote:

> Hi Nazeer,
>
> On Fri, May 13, 2016 at 4:44 PM, Nazeer Shaik <
> nazeer.sh...@confluxtechnologies.com> wrote:
>
> > Hi Terence,
> >
> > Can you tell me what is the use case to have all share accounts?
> Currently
> > it is implemented per client basis as I don't really find use of
> returning
> > all share accounts.
>
>
> ​Some use cases:​
>
>
>1. ​A Financial Institution having micro savings and credit recently
>added shares. This FI has 500,000 clients and in a month about 1% of
> these
>clients apply for shares so we have 5,000 clients with share accounts.
> The
>management wants to know some information such as:
>1. Total number of share accounts
>   1.  with the existing functionality I'll have to do something like
>  1. Initialize a total share accounts counter
> 2. Get list of clients, f
> oreach Client
>1. Get accounts for that client
>2. Ignore savings and loan accounts, pick shareaccounts
>3. Increment the counter by number of share accounts
>3. ​Report the result​
>
> 4. The efficiency of the above is 500,000 - the number of
> clients and the number of requests is also 500,000
> 2. ​if we had a get all share accounts facility, I could
>  1. call it and get the share account list and count in 1 request
> 2. Number of clients having share accounts:
>   1.  with the existing functionality I'll have to do something like
>  1. Initialize a total clients having share accounts counter
> 2. Get list of clients, f
> oreach Client
>1. Get accounts for that client
>2. Ignore savings and loan accounts, pick shareaccounts
>3. Increment the counter if share accounts length > 0
>2. ​if we had a get all share accounts facility, I could
>  1. call it and get the share account list
> 2. populate a Hash / Map object which tells whether a client
> has the share account or not
>
> 3. ​return the number of keys in the hash (number of clients
> which have a share account)​
>
> 3. Total value of shares bought by all clients
>   1. ​with the existing functionality, I'll have to iterate through
>  clients and for each ​client
>
>  1. get share account list and iterate over it and for each share
> account
> 1. get the number of shares and the unit price and multiply to
>get the share value for that client
>2. Add this to a counter
>2. if we could get all shares in 1 API call, I could iterate
>  over it and
>  1. multiple the share unit price with number of shares and sum the
> product
> 2. If I have multiple share products and want a breakup of
>share accounts # based on share product and client to gauge which
> products
>are more popular again with the existing API it's painfully inefficient
> for
>both application programmer and use
>​.
>
> ​
> ​I could think of any number of similar reporting or aggregation functions
>
> We are returning truncated data as data size will be more in case of
> > returning all share products and client is not really going to use entire
> > available data. In case of single product we are returning the complete
> > data.
> >
>
> ​This is fine but as API designers we can build flags like?fields=a,b,c to
> get a truncated list. So an application developer builing on top of the API
> can ​choose which fields they want and hence reduce the data size so this
> is an alternative design which imo has the benefits you mention but doesn't
> limit the application options and wider usability of the API.
>
>
> > Thanks,
> > Nazeer
> >
> >
> > On Fri, May 13, 2016 at 4:31 PM, Terence Monteiro <
> > tere...@sanjosesolutions.in> wrote:
> >
> > > Hi Nazeer,
> > >
> > > Thanks for your response. I'm aware this is one way of getting the
> share
> > > accounts for an individual client. I wanted to know if there is a way
> to
> > > get for all clients. For instance if I GET
> > > /fineract-provider/api/v1/savingsaccounts, I get all the savings
> > accounts.
> > > One use case of this is where say out of 5000 clients 5 have share
> > > accounts. If I had to do a per client method, I'd have to make 5000
> > > requests. But I'd like a way to query all share accounts of all clients
> > in
> > > a single query - in this case I should get 5 share accounts returned
> and
> > > since each has a 

[GitHub] incubator-fineract pull request: Easier Setup

[avikganguly01]

GitHub user avikganguly01 opened a pull request:

https://github.com/apache/incubator-fineract/pull/117

Easier Setup

Change in default exclusion so that ServerApplication and 
EmbeddedTomcatWithSSLConfiguration are default available in build path.
Inclusion of commons-io dependency as FileUtils in the excluded 
EmbeddedTomcatWithSSLConfiguration requires this dependency.

Changing sort function used in InterestRateChart to be compatible with Java 
7 as well since I believe not all users would have moved to Java 8 by now.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/avikganguly01/incubator-fineract develop

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-fineract/pull/117.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #117


commit d282ccbdc021578d96f5284a0611aae88aef9318
Author: avikganguly01 
Date:   2016-05-14T22:02:13Z

Easier Setup




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (FINERACT-3) Move MIFOS issues to FINERACT

[Roman Shaposhnik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283616#comment-15283616
 ] 

Roman Shaposhnik commented on FINERACT-3:
-

[~mgeiss] I am also curious as to how this migration is going and what help do 
you need. Questions like the one from [~meta-coder] show exactly what the 
problem with this split set up. 

> Move MIFOS issues to FINERACT
> -
>
> Key: FINERACT-3
> URL: https://issues.apache.org/jira/browse/FINERACT-3
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Pierre Smits
>Assignee: Markus Geiss
>
> Currently all open issues reside at https://mifosforge.jira.com.
> In order to draw the contributors into the Fineract project all open issues 
> should be migrated to the JIRA of the project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: All Share Accounts

[Terence Monteiro]

Hi Nazeer,

On Fri, May 13, 2016 at 4:44 PM, Nazeer Shaik <
nazeer.sh...@confluxtechnologies.com> wrote:

> Hi Terence,
>
> Can you tell me what is the use case to have all share accounts? Currently
> it is implemented per client basis as I don't really find use of returning
> all share accounts.


​Some use cases:​


   1. ​A Financial Institution having micro savings and credit recently
   added shares. This FI has 500,000 clients and in a month about 1% of these
   clients apply for shares so we have 5,000 clients with share accounts. The
   management wants to know some information such as:
   1. Total number of share accounts
  1.  with the existing functionality I'll have to do something like
 1. Initialize a total share accounts counter
2. Get list of clients, f
oreach Client
   1. Get accounts for that client
   2. Ignore savings and loan accounts, pick shareaccounts
   3. Increment the counter by number of share accounts
   3. ​Report the result​

4. The efficiency of the above is 500,000 - the number of
clients and the number of requests is also 500,000
2. ​if we had a get all share accounts facility, I could
 1. call it and get the share account list and count in 1 request
2. Number of clients having share accounts:
  1.  with the existing functionality I'll have to do something like
 1. Initialize a total clients having share accounts counter
2. Get list of clients, f
oreach Client
   1. Get accounts for that client
   2. Ignore savings and loan accounts, pick shareaccounts
   3. Increment the counter if share accounts length > 0
   2. ​if we had a get all share accounts facility, I could
 1. call it and get the share account list
2. populate a Hash / Map object which tells whether a client
has the share account or not

3. ​return the number of keys in the hash (number of clients
which have a share account)​

3. Total value of shares bought by all clients
  1. ​with the existing functionality, I'll have to iterate through
 clients and for each ​client

 1. get share account list and iterate over it and for each share
account
1. get the number of shares and the unit price and multiply to
   get the share value for that client
   2. Add this to a counter
   2. if we could get all shares in 1 API call, I could iterate
 over it and
 1. multiple the share unit price with number of shares and sum the
product
2. If I have multiple share products and want a breakup of
   share accounts # based on share product and client to gauge which products
   are more popular again with the existing API it's painfully inefficient for
   both application programmer and use
   ​.

​
​I could think of any number of similar reporting or aggregation functions

We are returning truncated data as data size will be more in case of
> returning all share products and client is not really going to use entire
> available data. In case of single product we are returning the complete
> data.
>

​This is fine but as API designers we can build flags like?fields=a,b,c to
get a truncated list. So an application developer builing on top of the API
can ​choose which fields they want and hence reduce the data size so this
is an alternative design which imo has the benefits you mention but doesn't
limit the application options and wider usability of the API.


> Thanks,
> Nazeer
>
>
> On Fri, May 13, 2016 at 4:31 PM, Terence Monteiro <
> tere...@sanjosesolutions.in> wrote:
>
> > Hi Nazeer,
> >
> > Thanks for your response. I'm aware this is one way of getting the share
> > accounts for an individual client. I wanted to know if there is a way to
> > get for all clients. For instance if I GET
> > /fineract-provider/api/v1/savingsaccounts, I get all the savings
> accounts.
> > One use case of this is where say out of 5000 clients 5 have share
> > accounts. If I had to do a per client method, I'd have to make 5000
> > requests. But I'd like a way to query all share accounts of all clients
> in
> > a single query - in this case I should get 5 share accounts returned and
> > since each has a clientId. Also considering the REST pattern, if
> > /path/to/resource/ gives me a single resource object, then
> > /path/to/resource should give me all the objects of that resource.
> >
> > A second question I have is regarding the get all share products API.
> This
> > currently returns a truncated set of fields. Let's say I have 1 share
> > product only on the server. If I do GET
> > /fineract-provider/api/v1/products/share I get:
> >
> > {
> > "totalFilteredRecords": 1,
> > "pageItems": [
> > {
> > "id": 2,
> >