Re: Database API table methods

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Database API table methods

Tim Lyons
Administrator

> On 3 Oct 2017, at 03:30, [hidden email] wrote:
>
>
> Date: Sun, 1 Oct 2017 17:43:08 +0100
> From: Nick Hall <[hidden email]>
> To: Gramps Development List <[hidden email]>
> Subject: [Gramps-devel] Database API table methods
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Devs,
>
> In the final part of my review of the public database methods I am now
> considering the get_table_names and get_table_metadata.
>
> 9541: DBAPI: Some methods should not form part of the public API
> https://gramps-project.org/bugs/view.php?id=9541
>
> The get_table_names method returns a list of class names of the table
> classes (primary classes? + Tag).
>
> The get_table_metadata method returns a dictionary of database methods
> related to a particular class.? This is useful when the object type is
> available in a variable.
>
> For example, to get an object from its type and handle:
>
> obj_type = 'Person'
> fnc = db.get_table_metadata(obj_type)['handle_func']
>
> An alternative would be to use:
>
> fnc = getattr(db, 'get_%s_from_handle' % obj_type.lower())
>
> Both return the get_person_from_handle method.
>
> Other entries that are defined include:
>
> gramps_id_func? :? get_%s_from_gramps_id
> handles_func? :? get_%s_handles
>
> Do we want to keep these methods?? If so, we should move them into a
> base class.? At the moment, they are incomplete and not consistent
> between backends.
>
> Do we want to rename them?
>
> Perhaps we should consider a similar function, such as:
>
> db.get_method('get_%s_from_handle, obj_type)
>
> I would be interested in your opinions.? These functions are not widely
> used, so it would be easy to change them.
>
> Regards,
>
>
> Nick.
>

As I say in https://gramps-project.org/bugs/view.php?id=9541#c50121, I think the methods that take the object type as a parameter should be removed, because most of the gramps code uses the methods that have the type in the name (e.g. get_%s_from_handle), and we should try to be consistent and not provide different ways of doing the same thing. Hence I prefer get_%s_from_gramps_id and get_%s_from_handle.

The get_table_metadata or getattr or get_method functions seem to me to be too dependent on the implementation (or at least to reflect the implementation too much).

I suppose the point is that most of the gramps code is specific to the particular structure that the code is trying to manipulate, so methods that are generic for all object types are not really that useful. (i.e. most of the code doesn’t essentially have the object type available as a variable).

Where an object can (for example) just be say a person or a family, I would prefer code like "if person, then get_person_from_gramps_id(..) else if family get_family_from_gramps_id(..) etc.”. All just for consistency with the majority of existing code.

Just my opinion from the code that I have tried to write or maintain. Maybe some of the code that you (Nick and Paul) are working on is more generic.

[I am of course only considering the public interfaces - the internal working of the database code is different].

Tim.

 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Database API table methods

Nick Hall
On 03/10/17 19:27, Tim Lyons wrote:
> I suppose the point is that most of the gramps code is specific to the particular structure that the code is trying to manipulate, so methods that are generic for all object types are not really that useful. (i.e. most of the code doesn’t essentially have the object type available as a variable).

Yes, most code follows links between objects and the method to use is known.

> Where an object can (for example) just be say a person or a family, I would prefer code like "if person, then get_person_from_gramps_id(..) else if family get_family_from_gramps_id(..) etc.”. All just for consistency with the majority of existing code.
>
> Just my opinion from the code that I have tried to write or maintain. Maybe some of the code that you (Nick and Paul) are working on is more generic.
>
One example where more generic code is needed is when a tag is deleted. 
We find the backlinks of the tag and then remove the tag from each
object type.  The find_backlink_handles method returns a list of
(object_type, handle) tuples.  Given the object type, we need to find
the appropriate get_%s_from_handle and commit_%s methods.

In such cases a utility standard function would be useful.  This could
contain "if" statements as you suggest.

I am asking if we want to provide a utility function.  If so, do we want
to keep get_table_metadata or provide something else?  If we decide to
keep get_table_metadata, then it should be moved into a base class.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel