Re: [Gramps-devel] An update, a warning, and a question

[Doug B. <dou...@gm...>]

On Mon, Dec 21, 2009 at 11:10 AM, Jon Clements <jo...@go...> wrote:
> I think we've got back very closely to what I was trying to say about the DB
> API/SimpleAccess jobby. Unfortunately personal issues have left me somewhat
> distracted, but I'll pull my finger out some time after xmas.

Yes, I think you are right... I'd love to see SimpleAccess go away,
and the functions that we keep get migrated over to this new
collection of useful, almost-methods.

-Doug

> Jon.
>
> Gerald Britton wrote:
>>
>> So, why not think about a "business logic" module that is really a
>> collection of functions for doing things such as your example?  Then
>> document it throughly and folks can import bits of it or all of if as
>> required.
>>
>> On Mon, Dec 21, 2009 at 9:52 AM, Doug Blank <dou...@gm...> wrote:
>>
>>>
>>> On Mon, Dec 21, 2009 at 9:27 AM, Gerald Britton
>>> <ger...@gm...> wrote:
>>>
>>>>
>>>> I'd be inclined to put functions like this in a separate module.  My
>>>> thinking goes like this:
>>>>
>>>> The base, read and write classes are concerned with moving data
>>>> to/from the database on disk and the methods in those classes reflect
>>>> that mandate.  For the most part, those classes are unaware of
>>>> relationships between the seven databases and I think that that is not
>>>> a bad thing.
>>>>
>>>> Now, your example concerns an event and searching for an event within
>>>> a list of events.  Why not add this method to the Event class itself?
>>>>
>>>
>>> If any particular method could go into such a class like Event, I'd be
>>> even happier to do that. However, I think Brian would still say that
>>> that is "business logic" and does not belong in any of these classes.
>>>
>>> But some other functionality might require the whole database as
>>> things need to be looked up, changed, etc. The problem about splitting
>>> up these functions based on what they do is that for anyone that is
>>> unfamiliar with the whole of gramps, it makes it hard to find these
>>> functions, or even know that they exist. This leads to a proliferation
>>> of similar functions, and some of them have slight bugs that might
>>> break database integrity. I'd rather keep all of these together in the
>>> most-appropriate class, and make sure that they are highly-tuned and
>>> polished.
>>>
>>> -Doug
>>>
>>>
>>>>
>>>> On Mon, Dec 21, 2009 at 1:33 AM, Doug Blank <dou...@gm...>
>>>> wrote:
>>>>
>>>>>
>>>>> Gramps devs,
>>>>>
>>>>> Following on the heels of Brian's changes to gen.db this weekend, I
>>>>> also jumped in and started cleaning up gen.utils. Brian was able to
>>>>> refactor some gui bits out of gen.db, and I made it so that gen.utils
>>>>> is separate from gen.lib. Part of my motivation was some major
>>>>> progress made on the gramps-connect front. I think we have the main
>>>>> flow worked out for the webapp:
>>>>>
>>>>> a) We'll use the very nice query interface built into Django. It is
>>>>> fast and very flexible.
>>>>> b) that will create a lazy list of matching items
>>>>> c) that list is passed to HTML templates which can be used to either
>>>>> edit or view public/private data
>>>>> d) if viewed, they will be looked up using Gramps' standard Database
>>>>> APIs (Regular, Proxy Living, Proxy, Private, etc)
>>>>>
>>>>> The short of this is that we don't have to replicate much code
>>>>> anywhere, and Gramps-Connect is now using ProxyDb. This is great, and
>>>>> things should start to fall into place more quickly now. (This took
>>>>> awhile to figure out!)
>>>>>
>>>>> Because of these changes (to gen.* and to web) be on the lookout for
>>>>> anything strange. You might want to .autogen.sh and make. A lot of
>>>>> code got moved around, and I might have missed something. I expect
>>>>> gramps-connect to be broken in trunk most of this week.
>>>>>
>>>>> Finally, a question. Brian and I were just having a discussion about
>>>>> where to put "business logic" code. For example, consider:
>>>>>
>>>>>   def marriage_from_eventref_list(db, eventref_list):
>>>>>       """
>>>>>       Get the marriage event from an eventref list.
>>>>>       """
>>>>>       for eventref in eventref_list:
>>>>>           event = db.get_event_from_handle(eventref.ref)
>>>>>           if event and event.type.is_marriage():
>>>>>               return event
>>>>>       return None
>>>>>
>>>>> This type of function has previously ended up in places like
>>>>> ReportBase.ReportUtils or gen.utils.dbutils depending on the functions
>>>>> perceived utility. I've put some of these functions as methods on
>>>>> gen.db.base.py (by changing db -> self). Brian has pointed out that
>>>>> base.py is a virtual class only. Furthermore, Brian says business
>>>>> logic does not belong in the database, and cited the Single
>>>>> Responsibility Principle [1]. However, to me these look like Db
>>>>> methods. If they are in the Db, then it makes it very easy to find
>>>>> them and use them (even from Django). Some of these methods might
>>>>> alter the database, so they don't all belong in a read-only proxy, and
>>>>> thus agree base is not the right place for them.
>>>>>
>>>>> The question:
>>>>>
>>>>> 1) should such methods be put in a Db class, say,  right above
>>>>> GrampsDbRead so that GrampsDb and Django can share them? Pros: they
>>>>> are all in one place. Cons: this code does all kinds of logic,
>>>>> breaking [1].
>>>>> 2) or should they be put in a module and used as functions? This does
>>>>> keep them separate, but you have to find them based on how there are
>>>>> categorized.
>>>>>
>>>>> I hope I portrayed Brian's opinion fairly.
>>>>>
>>>>> Comments or ideas on this issue?
>>>>>
>>>>> -Doug
>>>>>
>>>>> [1] - http://en.wikipedia.org/wiki/Single_responsibility_principle
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>>> Take advantage of Verizon's best-in-class app development support
>>>>> A streamlined, 14 day to market process makes app distribution fast and
>>>>> easy
>>>>> Join now and get one step closer to millions of Verizon customers
>>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>>> _______________________________________________
>>>>> Gramps-devel mailing list
>>>>> Gra...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>>
>>>>>
>>>>
>>>> --
>>>> Gerald Britton
>>>>
>>>>
>>
>>
>>
>>
>
>