Menu
▾
▴
Re: [Mifos-developer] Mobile / SMS (WAS: Re: [Mifos-users] SolDevelo will support the 2.2.x branch)
|
From: Keith W. <kei...@gm...> - 2011-10-30 12:44:02
|
Micheal, Udai, John, I couldnt resist chiming in on this email :) I read back over the emails to get some context. Michael reached out for help on two points: > 1. Write and post here a SQL query on the Mifos DB which returns "all > centers' collections for today" - with columns such as CenterID, > CenterName, CenterNoOfMembers, LOName, LOMobileNo, TotalAmountDue, > TodayDate? That would really help (me, or anybody else who wants to > jump on) to move forward with this. [I'm dreaming of some "Generic > REST API", configurable dynamically via SQL; let's see.] John has said that he has SQL queries to get to pass this (or if not he'll just write them for you) Generic REST API may not be really needs as its a concrete use case you are trying to do which is essentially 'retreive/query' and enter a 'full collection sheet' by providing centerId and date of collection (i guess the date is even optional and should default to today if not provided etc as idea of sms based service is to allow data entry happen closer to real time but not harm having ability to enter yesterdays or another days date either) > 2. Clarify how, assuming FULL and knowing CenterID & Date (and > TotalAmountDue, although that's implicit?), assuming that's > sufficient, the Collection can be "ticked off" (do you know what I > mean?). I am looking for details about the respective REST API, if it > already exists; or clarification that this would still have to be > built - with apologies if this is already on the list or Wiki and I > haven't caught up. Udai has put some rest services in front of existing java services already so should be a breeze for him to put a rest service for this which eventually will call the SQL queries provided by John. Johns point about '..getting something working is more important than too much approach-talk..' is very relevant here. If we do the above we unblock Michael and it is not much effort it seems for those involved. On the talk about a generic REST API. John was making a point about 'reporting' and about providing something that allows us to 'get out of the way' of people who want to get information from the database. So providing something that generically allows a reporting user to write some 'query' might be useful. He stated that he will '.. be trying to find out whether this assumption is right pretty soon by trying it out with MFI's..." So this is a bit of scope for getting past michaels problems at present and we will come back to this at some point in the future. The SQL versus HQL and Data versus Object debate: I have to say I side on the camp of 'using JDBC and SQL' to get at data is more than fine. Theres no need to always go through an ORM tool like Hibernate. There is a place for 'Data' and a place for 'Object-Orientation' in an information system. The only reason someone uses an ORM tool is when they put value on 'OO' as it helps deal with the Object-relational impedance mismatch. And we do value OO but we value 'Data' also in an information system. So the question is, where is the 'objects approach' valuable and where is the 'data' approach valuable. Often on the read side - we just want to get at 'data' so we can display it in some way to someone or something (like michael V at present). Its normal also that we want to 'de normalise' the data as it is stored on the relational database and give it back in a 'flat' way. Added to this, we only request data to 'act on it' so we typically end up 'writing' it back into the system. If this 'write' involves some level of complexity in dealing with (i.e. check everything is valid and business rules and satisfied) they we typically would like to deal with this 'data' in the form of 'domain objects' and if this data exists across and a number of tables, its nice to have an ORM simplify the write of this to the database. Keith On Sun, Oct 30, 2011 at 7:04 AM, Udai Gupta <mai...@gm...> wrote: >> You could certainly add methods to return centers meeting on a certain date >> etc to the existing collection sheet api but they are not there now. And I'd >> use sql rather than hibernate to return the data quickly and easily. I'd >> even change the existing method that gets collection sheet data for a center >> to be mostly sql if I was working on it again. But I recognise whoever is >> doing work around that area could have different approaches. > > Are you saying that Hibernate is a pseudo abstraction, there is no > point in trying to keep things relevant to Object model when it comes > to read only queries? I don't think it is about personnel preference, > it is more about why ORM exists. > >> can't see a problem adding whatever security is needed. You can also put >> limits to data size etc. But mainly you want to give complete access to the >> database to the people whose data it is. > > No, we have rules in application like one branch user(LO) can't have > access to data of other branch. so we can't expose all information > right to one user, and if we maintain those permission and security at > SQL level then it will be DRY violation and difficult to maintain. > >>> what about write queries (SQL injections). >> That's a simple validation > > I may have missed Michael's point "I could make something generic > which (internally) just takes a query string". If it means read-only > SQL queries in Mifos as string using PreparedStatement then it's fine. > But if it means that a SQL is given as a parameter from REST interface > then I would like to know what simple validation can prevent that > because when you are passing a SQL string which is used for executing, > one can easily append it execute another SQL. > >> I like use-cases too but there's many ways to skin a cat. yeah, a generic >> REST service which returns json recordset would be neat... maybe there's a >> utility out there already. > > I wouldn't be surprised if there is any such utility, but the point is > if SQL is not pre-compiled and coming in as a parameter how can you > restrict read/write/delete from that utility. > > Udai > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > Mifos-developer mailing list > mif...@li... > Unsubscribe or change settings at: > https://lists.sourceforge.net/lists/listinfo/mifos-developer |