DB-API configuration changes

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

DB-API configuration changes

DS Blank
Nick,

I have some concerns over the changes in this commit, "Move DBAPI default settings into an XML file":

https://github.com/gramps-project/gramps/commit/746cf0ee1e033c7a105af67c9e0ddd23c2cb713f

Prior to this commit, one could fine-tune a database connection by editing the default_settings.py in the database directory. Now, such changes are impossible (without changing core gramps.)

The reason why the database creation and connection was Python code was that there are too many connection variations to hardcode in the manner that this commit does.

Prior to this commit, all options to the constructors were passed to the connection creation code.

After this commit it is no longer possible for:

* a postgresql user to use async, or connection_factory, etc
* a sqlite user to use timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements, uri, etc
* a mysql user to use unix_socket, conv, conection_timeouts, compress, named_pipes, use_unicode, etc

Also, moving to XML will make other options difficult, such as "9418: Allow setting a password for DBI-API supported backends, via the main GUI and Command line.":


After the commit, we will have to make up a new config values to pass such requests (eg, "ask for a password") from the XML to Python. This is going to be more code for no gain. 

Perhaps you were attempting to work on "9544: DBAPI: The mechanism for dbapi backend choice is not suitable for users":

https://gramps-project.org/bugs/view.php?id=9544

But I disagree that this is an issue, and would not suggest that this commit is a way to address it. Changing DB-API's is not something most users will ever do. But when they want to, they should have access to all of the options available for whatever SQL server they are using. 

I suggest you revert this commit, and we can discuss if #9544 is really an issue, and if so how to address it.

-Doug

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Tim Lyons
Administrator
DS Blank wrote
Prior to this commit, one could fine-tune a database connection by editing
the default_settings.py in the database directory. Now, such changes are
impossible (without changing core gramps.)
Well, that rather depends on what one sees as the purpose of Gramps. I see it as a ready to run Family history program for use by non-programmers.

I don't see it as a library of parts for use by system integrators.

Regards,
Tim.
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
In reply to this post by DS Blank
On 06/07/16 13:08, Doug Blank wrote:
> Perhaps you were attempting to work on "9544: DBAPI: The mechanism for
> dbapi backend choice is not suitable for users":
>
> https://gramps-project.org/bugs/view.php?id=9544
>

Sorry for the delay in my reply.

Yes, this is what I was working on.

I agree with Tim when he says:  "Well, that rather depends on what one
sees as the purpose of Gramps. I see it as a ready to run Family history
program for use by non-programmers."

Normal users should not be allowed to choose the backend.  I suggest
that we remove the backend selection from the preferences.  Power users
can use the database section in the gramps.ini file.

We should provide the user with backend and configuration options that
we consider to be best for general use.


Nick.


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Michel Vuijlsteke
+1

On 11 July 2016 at 22:02, Nick Hall <[hidden email]> wrote:
On 06/07/16 13:08, Doug Blank wrote:
> Perhaps you were attempting to work on "9544: DBAPI: The mechanism for
> dbapi backend choice is not suitable for users":
>
> https://gramps-project.org/bugs/view.php?id=9544
>

Sorry for the delay in my reply.

Yes, this is what I was working on.

I agree with Tim when he says:  "Well, that rather depends on what one
sees as the purpose of Gramps. I see it as a ready to run Family history
program for use by non-programmers."

Normal users should not be allowed to choose the backend.  I suggest
that we remove the backend selection from the preferences.  Power users
can use the database section in the gramps.ini file.

We should provide the user with backend and configuration options that
we consider to be best for general use.


Nick.


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Paul Franklin-5
In reply to this post by Nick Hall
On 7/11/16, Nick Hall <[hidden email]> wrote:
> I agree with Tim when he says:  "Well, that rather depends on what one
> sees as the purpose of Gramps. I see it as a ready to run Family history
> program for use by non-programmers."

I agree with that too.

> Normal users should not be allowed to choose the backend.  I suggest
> that we remove the backend selection from the preferences.  Power users
> can use the database section in the gramps.ini file.

I agree with that too.

As I have said before, I also think the "Convert" button
on the FTM should be eliminated.

> We should provide the user with backend and configuration options that
> we consider to be best for general use.

I agree with that too.

Let's keep in mind we're doing gramps for our users.

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Jiri Kastner
In reply to this post by Nick Hall
On Mon, 11 Jul 2016 21:02:07 +0100, Nick Hall wrote:
> We should provide the user with backend and configuration options that
> we consider to be best for general use.

in that case you forgot very important variable: port
or i overlooked something in commits :)

use case:
i'm using gramps v5 with postgresql running on non-default port,
because on 5432 is listening postgresql for 'production' applications.
i have postgresql cluster with datadir in home directory
and tablespaces on removable devices (playing with openstreetmap database).
i use this setup for development and testing. when i screw something up,
in worst case, i just remove folders and start again.
same should be applied to mariadb/mysql.

j.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

DS Blank
On Tue, Jul 12, 2016 at 5:03 AM, Jiri Kastner <[hidden email]> wrote:
On Mon, 11 Jul 2016 21:02:07 +0100, Nick Hall wrote:
> We should provide the user with backend and configuration options that
> we consider to be best for general use.

in that case you forgot very important variable: port
or i overlooked something in commits :)

This is exactly my point. If the XML doesn't include the one parameter that a user needs, then a very important variable has been overlooked. And there are many, many of these. As I mentioned:

* a postgresql user to use async, or connection_factory, etc
* a sqlite user to use timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements, uri, etc
* a mysql user to use unix_socket, conv, conection_timeouts, compress, named_pipes, use_unicode, etc

This list will increase as we add more SQL implementations.

And you didn't mention how you would get a password from the GUI or CLI. Sure you can make up arbitrary symbols in the XML. But why create a new language?

In the end, you'll end up replicating the Python interface in XML. This will make many things much more difficult for the developers and for the user. 

What if Jiri wanted to pass in the port number via an environment variable? Now it is impossible (without changing core code).

I don't think the manner of setting up the SQL interface was too complex. Here it is:

"""
path_to_db = os.path.join(os.path.dirname(os.path.realpath(__file__)),
                          'sqlite.db')
dbapi = Sqlite(path_to_db)
"""

That is it. If a user needs to use one of the less common parameters, they just pass it into Sqlite. After this commit, any variation is impossible (without changing core).

A better solution would be to make something similar to the gpr.py files that we use for plugins. But even then, we need to be able to define the parameters. Something like:

dbapi(
    sql    = 'Sqlite',
    path  = os.path.join(os.path.dirname(os.path.realpath(__file__)),
                          'sqlite.db'),
    args = {"port": 5432},
)

But why do this? As I mentioned, few will ever what to change anything, but when they do, they should be able to change everything.

-Doug
 

use case:
i'm using gramps v5 with postgresql running on non-default port,
because on 5432 is listening postgresql for 'production' applications.
i have postgresql cluster with datadir in home directory
and tablespaces on removable devices (playing with openstreetmap database).
i use this setup for development and testing. when i screw something up,
in worst case, i just remove folders and start again.
same should be applied to mariadb/mysql.

j.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
On 12/07/16 12:05, Doug Blank wrote:
in that case you forgot very important variable: port
or i overlooked something in commits :)

This is exactly my point. If the XML doesn't include the one parameter that a user needs, then a very important variable has been overlooked. And there are many, many of these. As I mentioned:

* a postgresql user to use async, or connection_factory, etc
* a sqlite user to use timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements, uri, etc
* a mysql user to use unix_socket, conv, conection_timeouts, compress, named_pipes, use_unicode, etc

This list will increase as we add more SQL implementations.

Most of the configuration should be done in core Gramps.

Hopefully we will be reducing the number of SQL implementations rather than increasing them.



And you didn't mention how you would get a password from the GUI or CLI. Sure you can make up arbitrary symbols in the XML. But why create a new language?

In the end, you'll end up replicating the Python interface in XML. This will make many things much more difficult for the developers and for the user. 

What if Jiri wanted to pass in the port number via an environment variable? Now it is impossible (without changing core code).

I don't think the manner of setting up the SQL interface was too complex. Here it is:

"""
path_to_db = os.path.join(os.path.dirname(os.path.realpath(__file__)),
                          'sqlite.db')
dbapi = Sqlite(path_to_db)
"""

That is it. If a user needs to use one of the less common parameters, they just pass it into Sqlite. After this commit, any variation is impossible (without changing core).

The idea was to standardise the implementation.  The user shouldn't need to know anything about the database or its configuration.



A better solution would be to make something similar to the gpr.py files that we use for plugins. But even then, we need to be able to define the parameters. Something like:

dbapi(
    sql    = 'Sqlite',
    path  = os.path.join(os.path.dirname(os.path.realpath(__file__)),
                          'sqlite.db'),
    args = {"port": 5432},
)

But why do this? As I mentioned, few will ever what to change anything, but when they do, they should be able to change everything.


The users shouldn't need to change any configuration settings.  We should provide the settings we feel are best for Gramps.  An advanced user can always modify core Gramps.  They can already change the BSDDB settings in this way.


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

DS Blank
On Tue, Jul 12, 2016 at 7:52 AM, Nick Hall <[hidden email]> wrote:
On 12/07/16 12:05, Doug Blank wrote:
in that case you forgot very important variable: port
or i overlooked something in commits :)

This is exactly my point. If the XML doesn't include the one parameter that a user needs, then a very important variable has been overlooked. And there are many, many of these. As I mentioned:

* a postgresql user to use async, or connection_factory, etc
* a sqlite user to use timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements, uri, etc
* a mysql user to use unix_socket, conv, conection_timeouts, compress, named_pipes, use_unicode, etc

This list will increase as we add more SQL implementations.

Most of the configuration should be done in core Gramps.

Hopefully we will be reducing the number of SQL implementations rather than increasing them.

One major point of using DBAPI is that this opens up opportunities for users to use their data in the manner that they wish. There are many SQL implementations, and there are multiple implementations in Python for each implementation. I would not remove options for users.
 




And you didn't mention how you would get a password from the GUI or CLI. Sure you can make up arbitrary symbols in the XML. But why create a new language?

In the end, you'll end up replicating the Python interface in XML. This will make many things much more difficult for the developers and for the user. 

What if Jiri wanted to pass in the port number via an environment variable? Now it is impossible (without changing core code).

I don't think the manner of setting up the SQL interface was too complex. Here it is:

"""
path_to_db = os.path.join(os.path.dirname(os.path.realpath(__file__)),
                          'sqlite.db')
dbapi = Sqlite(path_to_db)
"""

That is it. If a user needs to use one of the less common parameters, they just pass it into Sqlite. After this commit, any variation is impossible (without changing core).

The idea was to standardise the implementation.  The user shouldn't need to know anything about the database or its configuration.

They don't need to know anything now. Moving these options from Python to XML does not make anything easier. It only makes some things harder or impossible.
 




A better solution would be to make something similar to the gpr.py files that we use for plugins. But even then, we need to be able to define the parameters. Something like:

dbapi(
    sql    = 'Sqlite',
    path  = os.path.join(os.path.dirname(os.path.realpath(__file__)),
                          'sqlite.db'),
    args = {"port": 5432},
)

But why do this? As I mentioned, few will ever what to change anything, but when they do, they should be able to change everything.


The users shouldn't need to change any configuration settings.  We should provide the settings we feel are best for Gramps.  An advanced user can always modify core Gramps.  They can already change the BSDDB settings in this way.

On the one hand, you are arguing that users shouldn't need to change anything, but also arguing that if they do, they need to change core gramps rather than their own default_settings.py file. 

Here is the biggest problem with this commit: if you change core gramps (say by simply adding an extra argument to a db constructor) then you have changed that interface for all SQL instances of that type. Your only option is to add that option to the XML so that each instance can control that parameter. That is a lot of work just to allow one instance to be slightly different from another.

-Doug
 



Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
On 12/07/16 13:27, Doug Blank wrote:
Hopefully we will be reducing the number of SQL implementations rather than increasing them.

One major point of using DBAPI is that this opens up opportunities for users to use their data in the manner that they wish. There are many SQL implementations, and there are multiple implementations in Python for each implementation. I would not remove options for users.

I think that this is a bad idea.  We should choose one database backend and implement it well.  We should also choose good configuration options.  The user doesn't even need to know what database we use.

I also think executing python code supplied with a database is a potential security risk.  What happens if the configuration is changed to include malicious code and then the database is shared with another user?  An XML configuration file is safer.

For 5.0, we need to support both BSDDB and SQLite.  However, in 5.1 we should only support a single backend.


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

paul womack
Nick Hall wrote:
>  The user doesn't even need to know what database we use.

What about all those genealogists out there with strong
preferences as to RDBMS vendor?

Oh yeah, they're quite rare ;-)

  BugBear


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Tom Hughes
On 12/07/16 14:00, paul womack wrote:
> Nick Hall wrote:
>>  The user doesn't even need to know what database we use.
>
> What about all those genealogists out there with strong
> preferences as to RDBMS vendor?
>
> Oh yeah, they're quite rare ;-)

Well speaking only for myself I can't wait to be able to get my gramps
data into Postgres... I will certainly sleep a lot more soundly!

Tom

--
Tom Hughes ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
--
Tom Hughes (tom@compton.nu)
http://compton.nu/
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

DS Blank
In reply to this post by Nick Hall
On Tue, Jul 12, 2016 at 8:50 AM, Nick Hall <[hidden email]> wrote:
On 12/07/16 13:27, Doug Blank wrote:
Hopefully we will be reducing the number of SQL implementations rather than increasing them.

One major point of using DBAPI is that this opens up opportunities for users to use their data in the manner that they wish. There are many SQL implementations, and there are multiple implementations in Python for each implementation. I would not remove options for users.

I think that this is a bad idea.  We should choose one database backend and implement it well.  We should also choose good configuration options.  The user doesn't even need to know what database we use.

Nick, I think you will find a good many users that want to use something other than sqlite, for many reasons. Postgresql and mysql are good alternatives, and are currently supported with all available options (before your commit). 

If we only wanted to support sqlite, then that would be quite a loss, and we could have designed the system without using DB-API: we could have used sqlite directly. But I purposefully designed for DB-API.

Using postgresql and mysql allows for things not possible with sqlite. It shouldn't be the default SQL implementation, but is a fantastic opportunity for those that want to use it.

Of course we want these to be supported well. Of course we want good configuration defaults. Of course the user doesn't need to know what DB is being used. Those are all true before and after converting Python to XML.
 

I also think executing python code supplied with a database is a potential security risk.  What happens if the configuration is changed to include malicious code and then the database is shared with another user?  An XML configuration file is safer.

Did you know that unpickling is a security risk? All of gramps` data is pickled. That means that all one has to do is insert into BSDDB or DB-API a single line, and the system is compromised. Did you know that all gpr.py files are Python code? Even third party addons. That means I can take over your machine with a line in a addon. 

You cannot argue against a Python config file because of security. I have thought a lot about security, even when running on the web (gramps-connect). Having a default_setting.py is fine.
 

For 5.0, we need to support both BSDDB and SQLite.  However, in 5.1 we should only support a single backend.

The plan (if all works well) is that backend to be DB-API + sqlite. But that doesn't mean it can't be DB-API + a user supplied variant, if they know what they are doing.

-Doug
 



Nick.



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
In reply to this post by Jiri Kastner
On 12/07/16 10:03, Jiri Kastner wrote:
> in that case you forgot very important variable: port
> or i overlooked something in commits:)

I can add a port option.


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

DS Blank
On Tue, Jul 12, 2016 at 9:41 AM, Nick Hall <[hidden email]> wrote:
On 12/07/16 10:03, Jiri Kastner wrote:
> in that case you forgot very important variable: port
> or i overlooked something in commits:)

I can add a port option.

Please don't! Just revert this commit. 

-Doug
 


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
In reply to this post by Tom Hughes
On 12/07/16 14:04, Tom Hughes wrote:
>>>  The user doesn't even need to know what database we use.
>>
>> What about all those genealogists out there with strong
>> preferences as to RDBMS vendor?
>>
>> Oh yeah, they're quite rare ;-)
>
> Well speaking only for myself I can't wait to be able to get my gramps
> data into Postgres... I will certainly sleep a lot more soundly!

We need to distinguish between a normal user and a power user here.

A normal user is only interested in family trees, not how they are
stored.  They certainly don't want to install or configure their own
database.

A power user may wish to run Postgres.  I would propose making its use
easy for a power user but not visible to a normal user.  Using the
gramps.ini file would make configuration easy for a non-programmer.


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

DS Blank
In reply to this post by Tom Hughes
On Tue, Jul 12, 2016 at 9:04 AM, Tom Hughes <[hidden email]> wrote:
On 12/07/16 14:00, paul womack wrote:
Nick Hall wrote:
 The user doesn't even need to know what database we use.

What about all those genealogists out there with strong
preferences as to RDBMS vendor?

Oh yeah, they're quite rare ;-)

Well speaking only for myself I can't wait to be able to get my gramps data into Postgres... I will certainly sleep a lot more soundly!

You are not alone.  The system was designed for you to be able to use Postgresql if you wish. But now you will have to wait for Nick to add each postgresl parameter that you wish to use in the XML. That's pretty silly.

Why?

* security? No
* because XML is easier to edit? No
* because Gramps should not be allowed to connect to postgresql? No

-Doug

 


Tom

--
Tom Hughes ([hidden email])
http://compton.nu/


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

DS Blank
In reply to this post by Nick Hall
On Tue, Jul 12, 2016 at 9:46 AM, Nick Hall <[hidden email]> wrote:
On 12/07/16 14:04, Tom Hughes wrote:
 The user doesn't even need to know what database we use.

What about all those genealogists out there with strong
preferences as to RDBMS vendor?

Oh yeah, they're quite rare ;-)

Well speaking only for myself I can't wait to be able to get my gramps data into Postgres... I will certainly sleep a lot more soundly!

We need to distinguish between a normal user and a power user here.

A normal user is only interested in family trees, not how they are stored.  They certainly don't want to install or configure their own database.

No one is arguing that.
 

A power user may wish to run Postgres.  I would propose making its use easy for a power user but not visible to a normal user.  Using the gramps.ini file would make configuration easy for a non-programmer.

We could expose some settings in the gramps.ini that are used in the default_settings.py file if that is your concern. I would be willing to write that.

-Doug
 



Nick.



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
In reply to this post by DS Blank
On 12/07/16 14:42, Doug Blank wrote:
> Please don't! Just revert this commit.
>

I don't plan to revert the commit.

We appear to have different goals here.  I am trying to make decisions
that make Gramps easy to maintain and benefit the majority of Gramps users.

However, I am interested to see what others think.


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: DB-API configuration changes

Nick Hall
In reply to this post by DS Blank
On 12/07/16 14:39, Doug Blank wrote:
For 5.0, we need to support both BSDDB and SQLite.  However, in 5.1 we should only support a single backend.

The plan (if all works well) is that backend to be DB-API + sqlite. But that doesn't mean it can't be DB-API + a user supplied variant, if they know what they are doing.


The single backend can be DB-API.  I am not against database variants, they don't add much extra code to maintain.


Nick.


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12