From: Gerald B. <ger...@gm...> - 2009-12-24 19:42:29
|
Let's ask a fundamental question: will we stick with the structure of seven object types plus meta and the ref maps or build an abstraction that makes that question just an implementation detail? Put another way: do we build upon what we have or look for a fresh start? If the latter then we will have lots more work to do and maybe not have a better gramps when we're done, just a different one. Remember that we are not trying to fix the world but build an application for a very specific purpose. I would opine that with such a goal, tight coupling between the biz logic and the back end is not a bad thing. I think at this point that I have no firm opinion either way though I believe that we should think long and hard and target Python 3.x at the same time. Perhaps gramps 4.0? On 12/24/09, Doug Blank <dou...@gm...> wrote: > On Thu, Dec 24, 2009 at 12:33 PM, Benny Malengier > <ben...@gm...> wrote: >> I'm sorry, I understand the words but don't get what you mean. >> In what I was saying, I assume the get_db to return something that has >> the database API and then all logic would work on all backends. >> The only problem is a bit how gen.lib now initializes the objects: >> from a bsddb table blob. > > I think the issue we are facing is how to cleanly separate *all* of > the business logic from *any* database implementation detail. Rather > than trying to roll our own (as either functions in libraries or as > methods in classes), I'm suggesting that we use an already established > database abstraction layer, and just implement our current code as a > backend to it. > > You hit the nail on the head with your question: do we want to write > mother(obj) or person.mother? But my story was meant to suggest that > we could use an already existing framework for answering exactly this > question. This would be a way towards database independence by > transitioning with our current codebase. > > I bring up this perhaps seemingly orthogonal issue now because I think > we are talking about developing and structuring a general interface to > the data, similar to SimpleAccess, but better. But we should seriously > think this over and consider a long term future. What do we want the > database of Gramps to look like in 3 to 5 years? > > I hoping that the code that we invest in this next layering can be > used in some future transition. > > Happy solstice season! > > -Doug > >> Benny >> >> 2009/12/24, Doug Blank <dou...@gm...>: >>> On Thu, Dec 24, 2009 at 6:20 AM, Benny Malengier >>> <ben...@gm...> wrote: >>>> About the issue of business logic, I would have thought an approach >>>> that injects the database to work on to be advantageous. So like >>>> simpleaccess a bit. >>>> One has a place that holds the db, whatever it is, and then calling >>>> the logic one needs uses this db to do whatever is needed. >>>> >>>> gen.logic.setup >>>> >>>> can have a DB global var, and set_db function, as well as a way to >>>> connect to a signal so that in gui changing db automatically >>>> reconnects for convenience. >>>> So one has access to the db as: >>>> from gen.logic.setup import get_db >>>> Then the logic functions work on the DB. >>>> So the logic is not part of gen.db as they span several tables and are >>>> about data logic integrity. They are also not part of gen.lib because >>>> they span several objects. >>>> >>>> The main decision to take is if we want: >>>> >>>> person.mother() >>>> or >>>> mother(object) >>>> >>>> For the first we need to extend the objects of gen.lib, for the second >>>> the logic works via methods. >>>> So the first would have something like >>>> >>>> from gen.lib.person import Person >>>> >>>> class PersonExt(Person): >>>> def __init__(self, handle) >>>> self.__db = get_db() >>>> Person.__init__(db.person_map(str(handle))) #yes must be done >>>> better >>>> def mother(): >>>> return >>>> self.__db.get_person_from_handle(self.get_main_parents_family_handle()) >>>> >>>> For the second we have something like: >>>> >>>> from gen.lib.person import Person >>>> def mother(object): >>>> db = get_db() >>>> if isinstance(object, Person): >>>> return >>>> db.get_person_from_handle(object.get_main_parents_family_handle()) >>>> elif isinstance(object, Family): >>>> .... >>>> >>>> In both cases gen.logic uses an instance of a db via gen.lib objects. >>>> So what does everyone prefer? >>>> >>>> I like such an approach better than adding things the gen.db, as some >>>> logic can be really convoluted. If we extend one of base db classes, >>>> we should avoid importing gen.lib, and that would make most logic >>>> really problematic to implement. >>>> >>>> Question is a bit if a djangodb would need specific changes to the >>>> generic logic which is now implicitly based on bsddb storage. >>>> About the original def marriage_from_eventref_list(db, eventref_list), >>>> this fits into this one way or the other.. >>>> >>>> So, how do we design this. We can only once take a choice >>> >>> Here is my thinking: >>> >>> Q: Do we want the database to be forever tied to BSDDB? >>> >>> A: No. It is always better if we have an option of databases. We can >>> still use BSDDB if we want, but it would be nice to use others as >>> well. >>> >>> Q: If that is the case, then you need to have *all* business logic >>> written in an abstract way, or you need to duplicate it for each >>> backend. Which do you want to do? >>> >>> A: It would be better to have it written just once. Otherwise it would >>> be a nightmare to maintain. >>> >>> Q: Ok, but this would be a lot of work for something that you don't >>> absolutely need. You have a lot of code invested in your own >>> transactions, and specialized Python database access. Do you really >>> want to abandon that? >>> >>> A: No, but how do we move toward database independence? >>> >>> Q: Hey, I ask the questions! One way to move forward is to implement >>> an abstract, backend-independent API, and use what you have to >>> implement the BSDDB backend. How does that sound? >>> >>> A: That sounds like too much work. We're a small team. >>> >>> Q: What if you could use a very well thought-out abstract layer, and >>> just connect the current system onto that? >>> >>> A: Yes, that sounds about right. And what we develop could be useful >>> to others that use the abstract layer that want to connect to BSDDB. >>> >>> Q: In the true open source spirit! This sounds like a way forward. >>> Good luck my question-asking friend. >>> >>> A: Thanks! >>> >>> -Doug >>> >>>> Benny >>>> >>> >> > -- Sent from my mobile device Gerald Britton |