Re: [Gramps-devel] Need some major testing in 3.0 for a recent change

[Serge N. <Ser...@fr...>]

=46ound two bugs in src/GrampsDbUtils/_GedcomParse.py

=46ist one line 3177 and second 3178 :

ERROR: DbLoader.py: line 502: Failed to import database.
Traceback (most recent call last):
  File "/usr/share/gramps/DbLoader.py", line 492, in do_import
    importer(self.dbstate.db, filename, self.uistate.pulse_progressbar)
  File "/usr/share/gramps/GrampsDbUtils/_ReadGedcom.py", line 69, in import=
Data
    import2(database, filename, callback, code_set, use_trans)
  File "/usr/share/gramps/GrampsDbUtils/_ReadGedcom.py", line 99, in import2
    close =3D gedparse.parse_gedcom_file(use_trans)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 911, in pars=
e_gedcom_file
    self.__parse_record()
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1256, in __p=
arse_record
    self.__parse_indi(line)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1359, in __p=
arse_indi
    self.__parse_level(state, self.indi_parse_tbl, self.__person_event)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1300, in __p=
arse_level
    func(line, state)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1597, in __p=
erson_std_event
    self.__parse_level(sub_state, self.event_parse_tbl, self.__undefined)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1300, in __p=
arse_level
    func(line, state)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 3177, in __e=
vent_inline_note
    self.__skip_subordinate_levels(level+2)
NameError: global name 'level' is not defined

correction : replace level by state.level

The second error:

34230: ERROR: DbLoader.py: line 502: Failed to import database.
Traceback (most recent call last):
  File "/usr/share/gramps/DbLoader.py", line 492, in do_import
    importer(self.dbstate.db, filename, self.uistate.pulse_progressbar)
  File "/usr/share/gramps/GrampsDbUtils/_ReadGedcom.py", line 69, in import=
Data
    import2(database, filename, callback, code_set, use_trans)
  File "/usr/share/gramps/GrampsDbUtils/_ReadGedcom.py", line 99, in import2
    close =3D gedparse.parse_gedcom_file(use_trans)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 911, in pars=
e_gedcom_file
    self.__parse_record()
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1256, in __p=
arse_record
    self.__parse_indi(line)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1359, in __p=
arse_indi
    self.__parse_level(state, self.indi_parse_tbl, self.__person_event)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1300, in __p=
arse_level
    func(line, state)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1597, in __p=
erson_std_event
    self.__parse_level(sub_state, self.event_parse_tbl, self.__undefined)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 1300, in __p=
arse_level
    func(line, state)
  File "/usr/share/gramps/GrampsDbUtils/_GedcomParse.py", line 3178, in __e=
vent_inline_note
    obj.add_note(new_note.get_handle())
NameError: global name 'obj' is not defined

Comment this line ?

Le/The jeudi 30 ao=FBt 2007, Don Allingham a =E9crit/wrote=A0:
> I've made a major change in the way we pull data out of the database.
> The new scheme should vastly improve report and export performance.
>=20
> Please try generating reports and exporting data with the current SVN
> branch. Report any problems to me.
>=20
> For those of you interested in the low level details, we were
> encountering some performance issues with object initialization. Every
> time we pull data out of the database, we have to create a new object,
> and then populate it.
>=20
> Typically, we did something like:
>=20
>    person =3D Person()
>    person.unserialize(data)
>=20
> The problem is that every data item is getting written twice. Once in
> the init routine, and once in the unserialize routine.
>=20
> I've been able to take advantage of the dynamic nature of python, and
> create an empty object, and then rely on the unserialize function to
> load the data properly. This can only be done safely when we are
> creating an object, and then directly and fully populating it.  So, the
> code ends up looking like:
>=20
>   import new
>=20
>   person =3D new.instance(Person, None)
>   person.unserialize(data)
>=20
> This prevents the double initialization, and leads to almost a 50%
> increase in performance.
>=20
> However, since this is a pretty bizarre and obscure thing to do, I would
> like to have some pretty heavy testing.
>=20
> So, please test.
>=20
> Don
>=20