From: Nick H. <nic...@ho...> - 2013-12-31 17:11:21
|
On 29/12/13 21:02, Doug Blank wrote: >> Perhaps we need to think about a gen.api module? This could also >> >incorporate the best ideas in the simple database access module. > Yes, I think that another layer that hides gen.lib and handle, but > builds on gen.lib, is a great idea, and not just for efficiency of > typing. > > Currently, we expose the (what should be internal) handles because > that is the only way to write code that can get the parents given a > family object. But we write that code over and over again. We really > do need a more abstract API. If we introduce that layer, then we could > gain a lot more than just another API... we could gain database > independence by using an API that allows us to talk to a variety of > backends, and some well-tested code that we only write once. > > Thinking ahead, if we wanted a new API to subsume the old gen.lib > objects, then we might not want to clean up the old gen.lib method > names if there was a chance that new names might clash with a new > abstraction layer. Of course, we have control over both interfaces, > but if we went with, say, Django's abstraction layer, then a few > things are fixed. But there are probably good reasons to make new > objects independent of the old ones. > > So, I think we can focus on the clean up of the gen.lib methods > independent of a new layer. Our current API is actually quite good. We just need enhance it, not radically change it. The enhancements could include some of the best aspects of the Django and simple database access interfaces. One approach would be to simply add a database instance to the constructor of the gen.lib objects. I suggested this when I was doing the file re-organisation. What we probably need is an interface defined in gen.api that is implemented by gen.lib, but this needs more thought. This doesn't affect the clean-up though. I still prefer the old get_X_from_handle and get_X_from_gramps_id methods. Perhaps we should start on the areas that are inconsistent to start with. Nick. |