db.cursor and no database

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

db.cursor and no database

jerome
Devs,


Should we not add something more for avoiding traceback like:

File "gramps/gui/editors/filtereditor.py", line 896, in on_add_clicked
    self.filter.get_name())
  File "gramps/gui/editors/filtereditor.py", line 573, in __init__
    taglist = taglist + [tag.get_name() for tag in dbstate.db.iter_tags()]
  File "gramps/gui/editors/filtereditor.py", line 573, in <listcomp>
    taglist = taglist + [tag.get_name() for tag in dbstate.db.iter_tags()]
  File "gramps/gen/db/read.py", line 1216, in g
    with curs_(self) as cursor:
  File "gramps/gen/db/read.py", line 532, in get_tag_cursor
    return self.get_cursor(self.tag_map, *args, **kwargs)
  File "gramps/gen/db/read.py", line 495, in get_cursor
    return DbReadCursor(table, self.txn)
  File "gramps/gen/db/read.py", line 182, in __init__
    self.cursor = source.db.cursor(txn)
AttributeError: 'dict' object has no attribute 'db'

To reproduce it on master:

1. open gramps, no family tree loaded
2. on any sidebar with filter gramplet, call the filter editor
3. On Filter editor, clic on [+] button for adding a filter rule

https://gramps-project.org/bugs/view.php?id=8250#c42039

Maybe adding a simple test for looking if the database exists
on: "gramps/gen/db/read.py", line 1216?

if self.dbstate.db.db_is_open:
    ....

or just no access to dbstate if the state
is not passing via a check?


regards,
Jérôme


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

DS Blank
On Fri, May 29, 2015 at 1:05 PM, jerome <[hidden email]> wrote:
Devs,


Should we not add something more for avoiding traceback like:

We'll have to come up with a solution that doesn't slow down normal code, and can catch many of these.

-Doug
 

File "gramps/gui/editors/filtereditor.py", line 896, in on_add_clicked
    self.filter.get_name())
  File "gramps/gui/editors/filtereditor.py", line 573, in __init__
    taglist = taglist + [tag.get_name() for tag in dbstate.db.iter_tags()]
  File "gramps/gui/editors/filtereditor.py", line 573, in <listcomp>
    taglist = taglist + [tag.get_name() for tag in dbstate.db.iter_tags()]
  File "gramps/gen/db/read.py", line 1216, in g
    with curs_(self) as cursor:
  File "gramps/gen/db/read.py", line 532, in get_tag_cursor
    return self.get_cursor(self.tag_map, *args, **kwargs)
  File "gramps/gen/db/read.py", line 495, in get_cursor
    return DbReadCursor(table, self.txn)
  File "gramps/gen/db/read.py", line 182, in __init__
    self.cursor = source.db.cursor(txn)
AttributeError: 'dict' object has no attribute 'db'

To reproduce it on master:

1. open gramps, no family tree loaded
2. on any sidebar with filter gramplet, call the filter editor
3. On Filter editor, clic on [+] button for adding a filter rule

https://gramps-project.org/bugs/view.php?id=8250#c42039

Maybe adding a simple test for looking if the database exists
on: "gramps/gen/db/read.py", line 1216?

if self.dbstate.db.db_is_open:
    ....

or just no access to dbstate if the state
is not passing via a check?


regards,
Jérôme


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

Nick Hall
In reply to this post by jerome
Jérôme,

This is a known problem.  The bug report is a duplicate of:

2092: Problems when no database is open
https://gramps-project.org/bugs/view.php?id=2092

It is very easy to reproduce errors of this type when no family tree is
open.

Nick.


On 29/05/15 18:05, jerome wrote:

> Should we not add something more for avoiding traceback like:
>
> File "gramps/gui/editors/filtereditor.py", line 896, in on_add_clicked
>      self.filter.get_name())
>    File "gramps/gui/editors/filtereditor.py", line 573, in __init__
>      taglist = taglist + [tag.get_name() for tag in dbstate.db.iter_tags()]
>    File "gramps/gui/editors/filtereditor.py", line 573, in <listcomp>
>      taglist = taglist + [tag.get_name() for tag in dbstate.db.iter_tags()]
>    File "gramps/gen/db/read.py", line 1216, in g
>      with curs_(self) as cursor:
>    File "gramps/gen/db/read.py", line 532, in get_tag_cursor
>      return self.get_cursor(self.tag_map, *args, **kwargs)
>    File "gramps/gen/db/read.py", line 495, in get_cursor
>      return DbReadCursor(table, self.txn)
>    File "gramps/gen/db/read.py", line 182, in __init__
>      self.cursor = source.db.cursor(txn)
> AttributeError: 'dict' object has no attribute 'db'
>
> To reproduce it on master:
>
> 1. open gramps, no family tree loaded
> 2. on any sidebar with filter gramplet, call the filter editor
> 3. On Filter editor, clic on [+] button for adding a filter rule
>
> https://gramps-project.org/bugs/view.php?id=8250#c42039
>
> Maybe adding a simple test for looking if the database exists
> on: "gramps/gen/db/read.py", line 1216?
>
> if self.dbstate.db.db_is_open:
>      ....
>
> or just no access to dbstate if the state
> is not passing via a check?


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

jerome
Nick,

Yes, maybe we can have two types?

If there is no database
    and
      close gramps when (while) an action is still running.

eg,
 self.__connect_secondary()
  File "gramps/gen/db/write.py", line 1003, in __connect_secondary
    db.DB_DUP | db.DB_DUPSORT)
  File "gramps/gen/db/write.py", line 414, in __open_db
    dbmap.open(fname, table_name, dbtype, DBFLAGS_O, DBMODE)
bsddb3.db.DBInvalidArgError: (22, 'Argument invalide -- BDB0633 DB_AUTO_COMMIT may not be specified in non-transactional environment')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "gramps/gui/plug/tool.py", line 252, in gui_tool
    callback = callback)
  File "gramps/plugins/tool/rebuild.py", line 81, in __init__
    self.db.rebuild_secondary(self.update)
  File "gramps/gen/db/write.py", line 402, in try_
    raise DbError(msg)
gramps.gen.errors.DbError: <unprintable DbError object>

What could be then the 'standard' message on bug reports?

True, both problems are very easy to reproduce, but we will
not only link next bug reports to #2092? Should we?

I thought that a Gtk spinner in relation with progress bar
might "force" user to wait, but that's something else.

About the gui (gramplet loaded) with no database,
maybe a minor design issue, but a fix
is possible, isn't it?


regards,
Jérôme


--------------------------------------------
En date de : Ven 29.5.15, Nick Hall <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: [hidden email]
 Date: Vendredi 29 mai 2015, 20h50
 
 Jérôme,
 
 This is a known problem.  The
 bug report is a duplicate of:
 
 2092: Problems when no database is open
 https://gramps-project.org/bugs/view.php?id=2092
 
 It is very easy to reproduce
 errors of this type when no family tree is
 open.
 
 Nick.
 
 
 On 29/05/15 18:05, jerome
 wrote:
 > Should we not add something more
 for avoiding traceback like:
 >
 > File
 "gramps/gui/editors/filtereditor.py", line 896, in
 on_add_clicked
 >     
 self.filter.get_name())
 >    File
 "gramps/gui/editors/filtereditor.py", line 573, in
 __init__
 >      taglist = taglist +
 [tag.get_name() for tag in dbstate.db.iter_tags()]
 >    File
 "gramps/gui/editors/filtereditor.py", line 573, in
 <listcomp>
 >      taglist =
 taglist + [tag.get_name() for tag in
 dbstate.db.iter_tags()]
 >    File
 "gramps/gen/db/read.py", line 1216, in g
 >      with curs_(self) as cursor:
 >    File
 "gramps/gen/db/read.py", line 532, in
 get_tag_cursor
 >      return
 self.get_cursor(self.tag_map, *args, **kwargs)
 >    File
 "gramps/gen/db/read.py", line 495, in
 get_cursor
 >      return
 DbReadCursor(table, self.txn)
 >    File
 "gramps/gen/db/read.py", line 182, in __init__
 >      self.cursor =
 source.db.cursor(txn)
 > AttributeError:
 'dict' object has no attribute 'db'
 >
 > To reproduce it on
 master:
 >
 > 1. open
 gramps, no family tree loaded
 > 2. on any
 sidebar with filter gramplet, call the filter editor
 > 3. On Filter editor, clic on [+] button
 for adding a filter rule
 >
 > https://gramps-project.org/bugs/view.php?id=8250#c42039
 >
 > Maybe adding a simple
 test for looking if the database exists
 >
 on: "gramps/gen/db/read.py", line 1216?
 >
 > if
 self.dbstate.db.db_is_open:
 >     
 ....
 >
 > or just no
 access to dbstate if the state
 > is not
 passing via a check?
 
 
 ------------------------------------------------------------------------------
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

DS Blank
On Sat, May 30, 2015 at 9:33 AM, jerome <[hidden email]> wrote:
Nick,

Yes, maybe we can have two types?

If there is no database
    and
      close gramps when (while) an action is still running.

Jérôme,

Let's save this issue for Gramps 5.0. I have some ideas on making the default read-only BSDDB object a bit better. I don't think we want to address this long-standing issue on the eve of the Gramps 4.2 string freeze, and going into bug fix mode.

-Doug
 

eg,
 self.__connect_secondary()
  File "gramps/gen/db/write.py", line 1003, in __connect_secondary
    db.DB_DUP | db.DB_DUPSORT)
  File "gramps/gen/db/write.py", line 414, in __open_db
    dbmap.open(fname, table_name, dbtype, DBFLAGS_O, DBMODE)
bsddb3.db.DBInvalidArgError: (22, 'Argument invalide -- BDB0633 DB_AUTO_COMMIT may not be specified in non-transactional environment')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "gramps/gui/plug/tool.py", line 252, in gui_tool
    callback = callback)
  File "gramps/plugins/tool/rebuild.py", line 81, in __init__
    self.db.rebuild_secondary(self.update)
  File "gramps/gen/db/write.py", line 402, in try_
    raise DbError(msg)
gramps.gen.errors.DbError: <unprintable DbError object>

What could be then the 'standard' message on bug reports?

True, both problems are very easy to reproduce, but we will
not only link next bug reports to #2092? Should we?

I thought that a Gtk spinner in relation with progress bar
might "force" user to wait, but that's something else.

About the gui (gramplet loaded) with no database,
maybe a minor design issue, but a fix
is possible, isn't it?


regards,
Jérôme


--------------------------------------------
En date de : Ven 29.5.15, Nick Hall <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: [hidden email]
 Date: Vendredi 29 mai 2015, 20h50

 Jérôme,

 This is a known problem.  The
 bug report is a duplicate of:

 2092: Problems when no database is open
 https://gramps-project.org/bugs/view.php?id=2092

 It is very easy to reproduce
 errors of this type when no family tree is
 open.

 Nick.


 On 29/05/15 18:05, jerome
 wrote:
 > Should we not add something more
 for avoiding traceback like:
 >
 > File
 "gramps/gui/editors/filtereditor.py", line 896, in
 on_add_clicked
 >     
 self.filter.get_name())
 >    File
 "gramps/gui/editors/filtereditor.py", line 573, in
 __init__
 >      taglist = taglist +
 [tag.get_name() for tag in dbstate.db.iter_tags()]
 >    File
 "gramps/gui/editors/filtereditor.py", line 573, in
 <listcomp>
 >      taglist =
 taglist + [tag.get_name() for tag in
 dbstate.db.iter_tags()]
 >    File
 "gramps/gen/db/read.py", line 1216, in g
 >      with curs_(self) as cursor:
 >    File
 "gramps/gen/db/read.py", line 532, in
 get_tag_cursor
 >      return
 self.get_cursor(self.tag_map, *args, **kwargs)
 >    File
 "gramps/gen/db/read.py", line 495, in
 get_cursor
 >      return
 DbReadCursor(table, self.txn)
 >    File
 "gramps/gen/db/read.py", line 182, in __init__
 >      self.cursor =
 source.db.cursor(txn)
 > AttributeError:
 'dict' object has no attribute 'db'
 >
 > To reproduce it on
 master:
 >
 > 1. open
 gramps, no family tree loaded
 > 2. on any
 sidebar with filter gramplet, call the filter editor
 > 3. On Filter editor, clic on [+] button
 for adding a filter rule
 >
 > https://gramps-project.org/bugs/view.php?id=8250#c42039
 >
 > Maybe adding a simple
 test for looking if the database exists
 >
 on: "gramps/gen/db/read.py", line 1216?
 >
 > if
 self.dbstate.db.db_is_open:
 >     
 ....
 >
 > or just no
 access to dbstate if the state
 > is not
 passing via a check?


 ------------------------------------------------------------------------------
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

jerome

--------------------------------------------
En date de : Sam 30.5.15, Doug Blank <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: "jerome" <[hidden email]>
 Cc: "Gramps Development List" <[hidden email]>, "Nick Hall" <[hidden email]>
 Date: Samedi 30 mai 2015, 15h48
 
 On Sat, May 30, 2015 at
 9:33 AM, jerome <[hidden email]>
 wrote:
 Nick,
 
 
 
 Yes, maybe we can have two types?
 
 
 
 If there is no database
 
     and
 
       close gramps when (while) an action is still
 running.
 
 Jérôme,
 
 Let's save this
 issue for Gramps 5.0. I have some ideas on making the
 default read-only BSDDB object a bit better. I don't
 think we want to address this long-standing issue on the eve
 of the Gramps 4.2 string freeze, and going into bug fix
 mode.
 -Doug 
 
 
No problem.

Note, 'Check and Repair' tool seems to have a solution by
using ProgressMeter (versus progress bar on most tools
and exporter)?

eg,

$ git grep ProgressMeter

returns many sections (on master)

While action runs, ProgressMeter
seems to freeze the main screen.
i.e. cannot close the database (except
by killing gramps)

Maybe not always a solution, but
a possible workaround.


Thanks.

-Jérôme





 
  self.__connect_secondary()
 
   File "gramps/gen/db/write.py", line 1003, in
 __connect_secondary
 
     db.DB_DUP | db.DB_DUPSORT)
 
   File "gramps/gen/db/write.py", line 414, in
 __open_db
 
     dbmap.open(fname, table_name, dbtype, DBFLAGS_O,
 DBMODE)
 
 bsddb3.db.DBInvalidArgError: (22, 'Argument invalide --
 BDB0633 DB_AUTO_COMMIT may not be specified in
 non-transactional environment')
 
 
 
 During handling of the above exception, another exception
 occurred:
 
 
 
 Traceback (most recent call last):
 
   File "gramps/gui/plug/tool.py", line 252, in
 gui_tool
 
     callback = callback)
 
   File "gramps/plugins/tool/rebuild.py", line 81,
 in __init__
 
     self.db.rebuild_secondary(self.update)
 
   File "gramps/gen/db/write.py", line 402, in
 try_
 
     raise DbError(msg)
 
 gramps.gen.errors.DbError: <unprintable DbError
 object>
 
 
 
 What could be then the 'standard' message on bug
 reports?
 
 
 
 True, both problems are very easy to reproduce, but we
 will
 
 not only link next bug reports to #2092? Should we?
 
 
 
 I thought that a Gtk spinner in relation with progress
 bar
 
 might "force" user to wait, but that's
 something else.
 
 
 
 About the gui (gramplet loaded) with no database,
 
 maybe a minor design issue, but a fix
 
 is possible, isn't it?
 
 
 
 
 
 regards,
 
 Jérôme
 
 
 
 
 
 --------------------------------------------
 
 En date de : Ven 29.5.15, Nick Hall <[hidden email]>
 a écrit :
 
 
 
  Objet: Re: [Gramps-devel] db.cursor and no database
 
  À: [hidden email]
 
  Date: Vendredi 29 mai 2015, 20h50
 
 
 
  Jérôme,
 
 
 
  This is a known problem.  The
 
  bug report is a duplicate of:
 
 
 
  2092: Problems when no database is open
 
  https://gramps-project.org/bugs/view.php?id=2092
 
 
 
  It is very easy to reproduce
 
  errors of this type when no family tree is
 
  open.
 
 
 
  Nick.
 
 
 
 
 
  On 29/05/15 18:05, jerome
 
  wrote:
 
  > Should we not add something more
 
  for avoiding traceback like:
 
  >
 
  > File
 
  "gramps/gui/editors/filtereditor.py", line 896,
 in
 
  on_add_clicked
 
  >     
 
  self.filter.get_name())
 
  >    File
 
  "gramps/gui/editors/filtereditor.py", line 573,
 in
 
  __init__
 
  >      taglist = taglist +
 
  [tag.get_name() for tag in dbstate.db.iter_tags()]
 
  >    File
 
  "gramps/gui/editors/filtereditor.py", line 573,
 in
 
  <listcomp>
 
  >      taglist =
 
  taglist + [tag.get_name() for tag in
 
  dbstate.db.iter_tags()]
 
  >    File
 
  "gramps/gen/db/read.py", line 1216, in g
 
  >      with curs_(self) as cursor:
 
  >    File
 
  "gramps/gen/db/read.py", line 532, in
 
  get_tag_cursor
 
  >      return
 
  self.get_cursor(self.tag_map, *args, **kwargs)
 
  >    File
 
  "gramps/gen/db/read.py", line 495, in
 
  get_cursor
 
  >      return
 
  DbReadCursor(table, self.txn)
 
  >    File
 
  "gramps/gen/db/read.py", line 182, in
 __init__
 
  >      self.cursor =
 
  source.db.cursor(txn)
 
  > AttributeError:
 
  'dict' object has no attribute 'db'
 
  >
 
  > To reproduce it on
 
  master:
 
  >
 
  > 1. open
 
  gramps, no family tree loaded
 
  > 2. on any
 
  sidebar with filter gramplet, call the filter editor
 
  > 3. On Filter editor, clic on [+] button
 
  for adding a filter rule
 
  >
 
  > https://gramps-project.org/bugs/view.php?id=8250#c42039
 
  >
 
  > Maybe adding a simple
 
  test for looking if the database exists
 
  >
 
  on: "gramps/gen/db/read.py", line 1216?
 
  >
 
  > if
 
  self.dbstate.db.db_is_open:
 
  >     
 
  ....
 
  >
 
  > or just no
 
  access to dbstate if the state
 
  > is not
 
  passing via a check?
 
 
 
 
 
  ------------------------------------------------------------------------------
 
  _______________________________________________
 
  Gramps-devel mailing list
 
  [hidden email]
 
  https://lists.sourceforge.net/lists/listinfo/gramps-devel
 
 
 
 ------------------------------------------------------------------------------
 
 _______________________________________________
 
 Gramps-devel mailing list
 
 [hidden email]
 
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
 
 
 

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

jerome
In reply to this post by jerome
Nick, Doug,


Attached a possible temp workaround, at least for DB repair tools.

OK, it is not designed for that: where are steps on ProgressMeter,
 quick workaround, etc ...

On the other hand, we should not quit gramps during
these processes.


regards,
Jérôme

--------------------------------------------
En date de : Sam 30.5.15, Doug Blank <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: "jerome" <[hidden email]>
 Cc: "Gramps Development List" <[hidden email]>, "Nick Hall" <[hidden email]>
 Date: Samedi 30 mai 2015, 15h48
 
 On Sat, May 30, 2015 at
 9:33 AM, jerome <[hidden email]>
 wrote:
 Nick,
 
 
 
 Yes, maybe we can have two types?
 
 
 
 If there is no database
 
     and
 
       close gramps when (while) an action is still
 running.
 
 Jérôme,
 
 Let's save this
 issue for Gramps 5.0. I have some ideas on making the
 default read-only BSDDB object a bit better. I don't
 think we want to address this long-standing issue on the eve
 of the Gramps 4.2 string freeze, and going into bug fix
 mode.
 -Doug 
 
 
 eg,
 
  self.__connect_secondary()
 
   File "gramps/gen/db/write.py", line 1003, in
 __connect_secondary
 
     db.DB_DUP | db.DB_DUPSORT)
 
   File "gramps/gen/db/write.py", line 414, in
 __open_db
 
     dbmap.open(fname, table_name, dbtype, DBFLAGS_O,
 DBMODE)
 
 bsddb3.db.DBInvalidArgError: (22, 'Argument invalide --
 BDB0633 DB_AUTO_COMMIT may not be specified in
 non-transactional environment')
 
 
 
 During handling of the above exception, another exception
 occurred:
 
 
 
 Traceback (most recent call last):
 
   File "gramps/gui/plug/tool.py", line 252, in
 gui_tool
 
     callback = callback)
 
   File "gramps/plugins/tool/rebuild.py", line 81,
 in __init__
 
     self.db.rebuild_secondary(self.update)
 
   File "gramps/gen/db/write.py", line 402, in
 try_
 
     raise DbError(msg)
 
 gramps.gen.errors.DbError: <unprintable DbError
 object>
 
 
 
 What could be then the 'standard' message on bug
 reports?
 
 
 
 True, both problems are very easy to reproduce, but we
 will
 
 not only link next bug reports to #2092? Should we?
 
 
 
 I thought that a Gtk spinner in relation with progress
 bar
 
 might "force" user to wait, but that's
 something else.
 
 
 
 About the gui (gramplet loaded) with no database,
 
 maybe a minor design issue, but a fix
 
 is possible, isn't it?
 
 
 
 
 
 regards,
 
 Jérôme
 
 
 
 
 
 --------------------------------------------
 
 En date de : Ven 29.5.15, Nick Hall <[hidden email]>
 a écrit :
 
 
 
  Objet: Re: [Gramps-devel] db.cursor and no database
 
  À: [hidden email]
 
  Date: Vendredi 29 mai 2015, 20h50
 
 
 
  Jérôme,
 
 
 
  This is a known problem.  The
 
  bug report is a duplicate of:
 
 
 
  2092: Problems when no database is open
 
  https://gramps-project.org/bugs/view.php?id=2092
 
 
 
  It is very easy to reproduce
 
  errors of this type when no family tree is
 
  open.
 
 
 
  Nick.
 
 
 
 
 
  On 29/05/15 18:05, jerome
 
  wrote:
 
  > Should we not add something more
 
  for avoiding traceback like:
 
  >
 
  > File
 
  "gramps/gui/editors/filtereditor.py", line 896,
 in
 
  on_add_clicked
 
  >     
 
  self.filter.get_name())
 
  >    File
 
  "gramps/gui/editors/filtereditor.py", line 573,
 in
 
  __init__
 
  >      taglist = taglist +
 
  [tag.get_name() for tag in dbstate.db.iter_tags()]
 
  >    File
 
  "gramps/gui/editors/filtereditor.py", line 573,
 in
 
  <listcomp>
 
  >      taglist =
 
  taglist + [tag.get_name() for tag in
 
  dbstate.db.iter_tags()]
 
  >    File
 
  "gramps/gen/db/read.py", line 1216, in g
 
  >      with curs_(self) as cursor:
 
  >    File
 
  "gramps/gen/db/read.py", line 532, in
 
  get_tag_cursor
 
  >      return
 
  self.get_cursor(self.tag_map, *args, **kwargs)
 
  >    File
 
  "gramps/gen/db/read.py", line 495, in
 
  get_cursor
 
  >      return
 
  DbReadCursor(table, self.txn)
 
  >    File
 
  "gramps/gen/db/read.py", line 182, in
 __init__
 
  >      self.cursor =
 
  source.db.cursor(txn)
 
  > AttributeError:
 
  'dict' object has no attribute 'db'
 
  >
 
  > To reproduce it on
 
  master:
 
  >
 
  > 1. open
 
  gramps, no family tree loaded
 
  > 2. on any
 
  sidebar with filter gramplet, call the filter editor
 
  > 3. On Filter editor, clic on [+] button
 
  for adding a filter rule
 
  >
 
  > https://gramps-project.org/bugs/view.php?id=8250#c42039
 
  >
 
  > Maybe adding a simple
 
  test for looking if the database exists
 
  >
 
  on: "gramps/gen/db/read.py", line 1216?
 
  >
 
  > if
 
  self.dbstate.db.db_is_open:
 
  >     
 
  ....
 
  >
 
  > or just no
 
  access to dbstate if the state
 
  > is not
 
  passing via a check?
 
 
 
 
 
  ------------------------------------------------------------------------------
 
  _______________________________________________
 
  Gramps-devel mailing list
 
  [hidden email]
 
  https://lists.sourceforge.net/lists/listinfo/gramps-devel
 
 
 
 ------------------------------------------------------------------------------
 
 _______________________________________________
 
 Gramps-devel mailing list
 
 [hidden email]
 
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

workaround_DB_tools.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

DS Blank
On Mon, Jun 1, 2015 at 9:31 AM, jerome <[hidden email]> wrote:
Nick, Doug,


Attached a possible temp workaround, at least for DB repair tools.

OK, it is not designed for that: where are steps on ProgressMeter,
 quick workaround, etc ...

On the other hand, we should not quit gramps during
these processes.

Yes, something like this would be good. There is now a CLI/GUI Progress function that is part of User... we have to use that so that this code can be used in either mode (which the tools is designed for).

-Doug
 


regards,
Jérôme

--------------------------------------------
En date de : Sam 30.5.15, Doug Blank <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: "jerome" <[hidden email]>
 Cc: "Gramps Development List" <[hidden email]>, "Nick Hall" <[hidden email]>
 Date: Samedi 30 mai 2015, 15h48

 On Sat, May 30, 2015 at
 9:33 AM, jerome <[hidden email]>
 wrote:
 Nick,



 Yes, maybe we can have two types?



 If there is no database

     and

       close gramps when (while) an action is still
 running.

 Jérôme,

 Let's save this
 issue for Gramps 5.0. I have some ideas on making the
 default read-only BSDDB object a bit better. I don't
 think we want to address this long-standing issue on the eve
 of the Gramps 4.2 string freeze, and going into bug fix
 mode.
 -Doug 


 eg,

  self.__connect_secondary()

   File "gramps/gen/db/write.py", line 1003, in
 __connect_secondary

     db.DB_DUP | db.DB_DUPSORT)

   File "gramps/gen/db/write.py", line 414, in
 __open_db

     dbmap.open(fname, table_name, dbtype, DBFLAGS_O,
 DBMODE)

 bsddb3.db.DBInvalidArgError: (22, 'Argument invalide --
 BDB0633 DB_AUTO_COMMIT may not be specified in
 non-transactional environment')



 During handling of the above exception, another exception
 occurred:



 Traceback (most recent call last):

   File "gramps/gui/plug/tool.py", line 252, in
 gui_tool

     callback = callback)

   File "gramps/plugins/tool/rebuild.py", line 81,
 in __init__

     self.db.rebuild_secondary(self.update)

   File "gramps/gen/db/write.py", line 402, in
 try_

     raise DbError(msg)

 gramps.gen.errors.DbError: <unprintable DbError
 object>



 What could be then the 'standard' message on bug
 reports?



 True, both problems are very easy to reproduce, but we
 will

 not only link next bug reports to #2092? Should we?



 I thought that a Gtk spinner in relation with progress
 bar

 might "force" user to wait, but that's
 something else.



 About the gui (gramplet loaded) with no database,

 maybe a minor design issue, but a fix

 is possible, isn't it?





 regards,

 Jérôme





 --------------------------------------------

 En date de : Ven 29.5.15, Nick Hall <[hidden email]>
 a écrit :



  Objet: Re: [Gramps-devel] db.cursor and no database

  À: [hidden email]

  Date: Vendredi 29 mai 2015, 20h50



  Jérôme,



  This is a known problem.  The

  bug report is a duplicate of:



  2092: Problems when no database is open

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



  It is very easy to reproduce

  errors of this type when no family tree is

  open.



  Nick.





  On 29/05/15 18:05, jerome

  wrote:

  > Should we not add something more

  for avoiding traceback like:

  >

  > File

  "gramps/gui/editors/filtereditor.py", line 896,
 in

  on_add_clicked

  >     

  self.filter.get_name())

  >    File

  "gramps/gui/editors/filtereditor.py", line 573,
 in

  __init__

  >      taglist = taglist +

  [tag.get_name() for tag in dbstate.db.iter_tags()]

  >    File

  "gramps/gui/editors/filtereditor.py", line 573,
 in

  <listcomp>

  >      taglist =

  taglist + [tag.get_name() for tag in

  dbstate.db.iter_tags()]

  >    File

  "gramps/gen/db/read.py", line 1216, in g

  >      with curs_(self) as cursor:

  >    File

  "gramps/gen/db/read.py", line 532, in

  get_tag_cursor

  >      return

  self.get_cursor(self.tag_map, *args, **kwargs)

  >    File

  "gramps/gen/db/read.py", line 495, in

  get_cursor

  >      return

  DbReadCursor(table, self.txn)

  >    File

  "gramps/gen/db/read.py", line 182, in
 __init__

  >      self.cursor =

  source.db.cursor(txn)

  > AttributeError:

  'dict' object has no attribute 'db'

  >

  > To reproduce it on

  master:

  >

  > 1. open

  gramps, no family tree loaded

  > 2. on any

  sidebar with filter gramplet, call the filter editor

  > 3. On Filter editor, clic on [+] button

  for adding a filter rule

  >

  > https://gramps-project.org/bugs/view.php?id=8250#c42039

  >

  > Maybe adding a simple

  test for looking if the database exists

  >

  on: "gramps/gen/db/read.py", line 1216?

  >

  > if

  self.dbstate.db.db_is_open:

  >     

  ....

  >

  > or just no

  access to dbstate if the state

  > is not

  passing via a check?





  ------------------------------------------------------------------------------

  _______________________________________________

  Gramps-devel mailing list

  [hidden email]

  https://lists.sourceforge.net/lists/listinfo/gramps-devel



 ------------------------------------------------------------------------------

 _______________________________________________

 Gramps-devel mailing list

 [hidden email]

 https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------

_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

jerome
In reply to this post by jerome
Ah sorry, maybe a possible block (indentation) issue.

On attached patch, self.progress is only available in uistate.
So, self.progress.close() location should be fixed.

Anyway, this was a sample of workaround for avoiding
traceback like:

self.__connect_secondary()
 
    File "gramps/gen/db/write.py", line 1003, in
  __connect_secondary
 
      db.DB_DUP | db.DB_DUPSORT)
 
    File "gramps/gen/db/write.py", line 414, in
  __open_db
 
      dbmap.open(fname, table_name, dbtype, DBFLAGS_O,
  DBMODE)
 
  bsddb3.db.DBInvalidArgError: (22, 'Argument invalide --
  BDB0633 DB_AUTO_COMMIT may not be specified in
  non-transactional environment')


regards,
Jérôme

--------------------------------------------
En date de : Lun 1.6.15, jerome <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: "Doug Blank" <[hidden email]>
 Cc: "Gramps Development List" <[hidden email]>
 Date: Lundi 1 juin 2015, 15h31
 
 Nick, Doug,
 
 
 Attached a possible temp workaround, at least for DB repair
 tools.
 
 OK, it is not designed for that: where are steps on
 ProgressMeter,
  quick workaround, etc ...
 
 On the other hand, we should not quit gramps during
 these processes.
 
 
 regards,
 Jérôme
 
 --------------------------------------------
 En date de : Sam 30.5.15, Doug Blank <[hidden email]>
 a écrit :
 
  Objet: Re: [Gramps-devel] db.cursor and no database
  À: "jerome" <[hidden email]>
  Cc: "Gramps Development List" <[hidden email]>,
 "Nick Hall" <[hidden email]>
  Date: Samedi 30 mai 2015, 15h48
 
  On Sat, May 30, 2015 at
  9:33 AM, jerome <[hidden email]>
  wrote:
  Nick,
 
 
 
  Yes, maybe we can have two types?
 
 
 
  If there is no database
 
      and
 
        close gramps when (while) an action is still
  running.
 
  Jérôme,
 
  Let's save this
  issue for Gramps 5.0. I have some ideas on making the
  default read-only BSDDB object a bit better. I don't
  think we want to address this long-standing issue on the
 eve
  of the Gramps 4.2 string freeze, and going into bug fix
  mode.
  -Doug 
 
 
  eg,
 
   self.__connect_secondary()
 
    File "gramps/gen/db/write.py", line 1003, in
  __connect_secondary
 
      db.DB_DUP | db.DB_DUPSORT)
 
    File "gramps/gen/db/write.py", line 414, in
  __open_db
 
      dbmap.open(fname, table_name, dbtype, DBFLAGS_O,
  DBMODE)
 
  bsddb3.db.DBInvalidArgError: (22, 'Argument invalide --
  BDB0633 DB_AUTO_COMMIT may not be specified in
  non-transactional environment')
 
 
 
  During handling of the above exception, another exception
  occurred:
 
 
 
  Traceback (most recent call last):
 
    File "gramps/gui/plug/tool.py", line 252, in
  gui_tool
 
      callback = callback)
 
    File "gramps/plugins/tool/rebuild.py", line 81,
  in __init__
 
      self.db.rebuild_secondary(self.update)
 
    File "gramps/gen/db/write.py", line 402, in
  try_
 
      raise DbError(msg)
 
  gramps.gen.errors.DbError: <unprintable DbError
  object>
 
 
 
  What could be then the 'standard' message on bug
  reports?
 
 
 
  True, both problems are very easy to reproduce, but we
  will
 
  not only link next bug reports to #2092? Should we?
 
 
 
  I thought that a Gtk spinner in relation with progress
  bar
 
  might "force" user to wait, but that's
  something else.
 
 
 
  About the gui (gramplet loaded) with no database,
 
  maybe a minor design issue, but a fix
 
  is possible, isn't it?
 
 
 
 
 
  regards,
 
  Jérôme
 
 
 
 
 
  --------------------------------------------
 
  En date de : Ven 29.5.15, Nick Hall <[hidden email]>
  a écrit :
 
 
 
   Objet: Re: [Gramps-devel] db.cursor and no database
 
   À: [hidden email]
 
   Date: Vendredi 29 mai 2015, 20h50
 
 
 
   Jérôme,
 
 
 
   This is a known problem.  The
 
   bug report is a duplicate of:
 
 
 
   2092: Problems when no database is open
 
   https://gramps-project.org/bugs/view.php?id=2092
 
 
 
   It is very easy to reproduce
 
   errors of this type when no family tree is
 
   open.
 
 
 
   Nick.
 
 
 
 
 
   On 29/05/15 18:05, jerome
 
   wrote:
 
   > Should we not add something more
 
   for avoiding traceback like:
 
   >
 
   > File
 
   "gramps/gui/editors/filtereditor.py", line 896,
  in
 
   on_add_clicked
 
   >     
 
   self.filter.get_name())
 
   >    File
 
   "gramps/gui/editors/filtereditor.py", line 573,
  in
 
   __init__
 
   >      taglist = taglist +
 
   [tag.get_name() for tag in dbstate.db.iter_tags()]
 
   >    File
 
   "gramps/gui/editors/filtereditor.py", line 573,
  in
 
   <listcomp>
 
   >      taglist =
 
   taglist + [tag.get_name() for tag in
 
   dbstate.db.iter_tags()]
 
   >    File
 
   "gramps/gen/db/read.py", line 1216, in g
 
   >      with curs_(self) as cursor:
 
   >    File
 
   "gramps/gen/db/read.py", line 532, in
 
   get_tag_cursor
 
   >      return
 
   self.get_cursor(self.tag_map, *args, **kwargs)
 
   >    File
 
   "gramps/gen/db/read.py", line 495, in
 
   get_cursor
 
   >      return
 
   DbReadCursor(table, self.txn)
 
   >    File
 
   "gramps/gen/db/read.py", line 182, in
  __init__
 
   >      self.cursor =
 
   source.db.cursor(txn)
 
   > AttributeError:
 
   'dict' object has no attribute 'db'
 
   >
 
   > To reproduce it on
 
   master:
 
   >
 
   > 1. open
 
   gramps, no family tree loaded
 
   > 2. on any
 
   sidebar with filter gramplet, call the filter editor
 
   > 3. On Filter editor, clic on [+] button
 
   for adding a filter rule
 
   >
 
   > https://gramps-project.org/bugs/view.php?id=8250#c42039
 
   >
 
   > Maybe adding a simple
 
   test for looking if the database exists
 
   >
 
   on: "gramps/gen/db/read.py", line 1216?
 
   >
 
   > if
 
   self.dbstate.db.db_is_open:
 
   >     
 
   ....
 
   >
 
   > or just no
 
   access to dbstate if the state
 
   > is not
 
   passing via a check?
 
 
 
 
 
   ------------------------------------------------------------------------------
 
   _______________________________________________
 
   Gramps-devel mailing list
 
   [hidden email]
 
   https://lists.sourceforge.net/lists/listinfo/gramps-devel
 
 
 
  ------------------------------------------------------------------------------
 
  _______________________________________________
 
  Gramps-devel mailing list
 
  [hidden email]
 
  https://lists.sourceforge.net/lists/listinfo/gramps-devel
 -----La pièce jointe associée suit-----
 
 ------------------------------------------------------------------------------
 
 -----La pièce jointe associée suit-----
 
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
 

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

Tim Lyons
Administrator
In reply to this post by DS Blank
DS Blank wrote
On Sat, May 30, 2015 at 9:33 AM, jerome <[hidden email]> wrote:

> Nick,
>
> Yes, maybe we can have two types?
>
> If there is no database
>     and
>       close gramps when (while) an action is still running.
>

Jérôme,

Let's save this issue for Gramps 5.0. I have some ideas on making the
default read-only BSDDB object a bit better. I don't think we want to
address this long-standing issue on the eve of the Gramps 4.2 string
freeze, and going into bug fix mode.
I'm not sure what the proposed patch fixes - I couldn't understand the very long quoted sections that had not been trimmed.

I think that if there is no database, then the database code should just crash [1] Gramps immediately.

(a) The database code doesn't know what a suitable response would be when there is no database

(b) It is the responsibility of the calling code not to be making the call when it is not appropriate.

(c) this follows the principle of 'fail early', making it obvious when the calling code is going wrong, and promoting a quicker fix to the calling code.

(d) crashing immediately means that the traceback shows where erroneous call happened, rather than the code struggling on and raising an exception or other error later on.



(The same thing applies both in this case of db.cursor with no db, and #8537 use of find_backlink_handles inside a batch transaction)

[1] raise an unhandled exception.

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

Re: db.cursor and no database

Josip
In reply to this post by jerome
30.5.2015. u 16:43, jerome je napisao/la:

> Note, 'Check and Repair' tool seems to have a solution by
> using ProgressMeter (versus progress bar on most tools
> and exporter)?
>
> eg,
>
> $ git grep ProgressMeter
>
> returns many sections (on master)
>
> While action runs, ProgressMeter
> seems to freeze the main screen.
> i.e. cannot close the database (except
> by killing gramps)
>
> Maybe not always a solution, but
> a possible workaround.

Note that user.progress is wrapper for ProgressMeter ;-)
ProgressMeter is modal only when parent is set and until recently from
most places it is called in such way ('Check and Repair' also). Without
parent declared there are no transient parent set, and without that
dialog my be at mercy of window manager who can open it behind main
window or on different monitor.
Not setting transient-parent causes problem now on recent gtk version
(at list on Windows OS) and is planed to be deprecated in the future.

Progress call ProgresMeter without parent argument.
I don't see a way to make default one in user.py as is so abstract.
Some code that calls it are also abstract but in most cases their
transient parent should be main Gramps window.

How to get access to main window from anywhere???

Newer gtk version also try to smooth progress animation so we need to be
more care-full with progress of progress-bar.


--
Josip

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

jerome

--------------------------------------------
En date de : Lun 1.6.15, Josip <[hidden email]> a écrit :

 Objet: Re: [Gramps-devel] db.cursor and no database
 À: [hidden email]
 Date: Lundi 1 juin 2015, 21h27
 
 30.5.2015. u 16:43,
 jerome je napisao/la:
 > Note, 'Check
 and Repair' tool seems to have a solution by
 > using ProgressMeter (versus progress bar
 on most tools
 > and exporter)?
 >
 > eg,
 >
 > $ git grep
 ProgressMeter
 >
 >
 returns many sections (on master)
 >
 > While action runs, ProgressMeter
 > seems to freeze the main screen.
 > i.e. cannot close the database (except
 > by killing gramps)
 >
 
 > Maybe not always a solution, but
 > a possible workaround.
 
 Note that user.progress is wrapper for
 ProgressMeter ;-)
 ProgressMeter is modal
 only when parent is set and until recently from
 most places it is called in such way
 ('Check and Repair' also). Without
 parent declared there are no transient parent
 set, and without that
 dialog my be at mercy
 of window manager who can open it behind main
 window or on different monitor.
 Not setting transient-parent causes problem now
 on recent gtk version
 (at list on Windows
 OS) and is planed to be deprecated in the future.
 
 Progress call ProgresMeter
 without parent argument.
 I don't see a
 way to make default one in user.py as is so abstract.
 Some code that calls it are also abstract but
 in most cases their
 transient parent should
 be main Gramps window.
 
 How
 to get access to main window from anywhere???
 
 Newer gtk version also try to
 smooth progress animation so we need to be
 more care-full with progress of
 progress-bar.
 
 
 --
 Josip



Ah yes, lazy implementation ...

Because need a dialog for informing the user:

"Please, Wait"
"Work in progress"
"Do not quit Gramps"
etc ...

It seems that if we do not inform about
any action, then after few seconds some
people are thinking that Gramps crashed
and they force to quit.

Progress Bar and Status Bar display
informations but either let the user
killing some signals or freeze GUI while
processes are pending. No solution!

So, to just include ProgressMeter instead
of user.progress was only a quick and lazy solution. ;-)

Note, here, uistate and db.cursor are using
a parent window. At least via the tool dialog, no?

The issue with gramplet, which can call Editors
without existing Family Tree opened, is cosmetic too.
As said, this means design change and more testing.
So, this can wait next major release.

Agreed with Tim, Gramps should maybe raise
a "non-python/DB" error. This will return
something like: "A known issue, we are working
on a proper fix, or will be fixed on next major releases"
instead of the db.cursor stuff.

I did not run the experimental "mantis gramplet"[1] on last months,
but if need, we can list some types of common errors already reported.
If know the cause, then bugs triage will be more efficient too.


[1] https://gramps-project.org/bugs/view.php?id=6601

--
Jérôme
 
 ------------------------------------------------------------------------------
 _______________________________________________
 Gramps-devel mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/gramps-devel
 

------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: db.cursor and no database

enno
Jerome, Josip,

> Ah yes, lazy implementation ...
>
> Because need a dialog for informing the user:
>
> "Please, Wait"
> "Work in progress"
> "Do not quit Gramps"
> etc ...
>
> It seems that if we do not inform about
> any action, then after few seconds some
> people are thinking that Gramps crashed
> and they force to quit.
True, and that happens even before start. I just ran a test with Windows
XP in VirtualBox, with 2 GB RAM, which is plenty for XP, on an i7, where
VirtualBox can safely use 1 core. And when I start 4.1.3 on that, more
than 10 seconds go by without any sign of activity. I see the same on my
laptop, with Windows 10 running as the main OS on an i3.

In both cases, it would be very nice if Gramps can show some progress
bar while loading something I don't know. Python files are all compiled,
so that can't be it, and in my XP test environment, there is no big
database either. Today's test led me to start Gramps twice, very dangerous.

regards,

Enno


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel