![]() I'm not sure in my mind why pending changes are, or should be an issue. It works from standard GEDCOM files, and is therefore compatible with every. Should it ever be possible to export a tree that still has pending changes? webtrees is the webs leading on-line collaborative genealogy application. Then if no other settings are changed from their defaults, use the new export function, otherwise use the old one. Mit der kostenlosen Open-Source Anwendung webtrees können Genealogien online bearbeitet und veröffentlicht werden. I would just call it "Export", and change the zip option to "Zip and download". Hence my suggestion to combine them, so the "no frills" version of Download uses the code now adjusted for Export. Not so easy to understand when the output from Download is the same as the output from Export. Its easy for users to understand that with complex additional options things might be slower, perhaps even slow enough that they won't work on some set ups. It works with standard GEDCOM files and is installed on a web server. FamilySearch GEDCOM version 7.0 incorporates the added ability to include photos and other files when users download a FamilySearch GEDCOM 7.0 file from a supported Family Tree product. Webtrees is a free, open source, website based, collaborative genealogy application. This update will allow more efficient managing and sharing of information. The bug's title is: "GEDCOM export/download hits memory limit", not "GEDCOM export hits memory limit". FamilySearch announced FamilySearch GEDCOM version 7.0 at RootsTech Connect 2021. So "Download", even with no pending changes, no privacy filtering, no re-writing media paths etc, will still not run for the people who have reported it to be an issue? Surely that means the bug is not "fixed". You could view this as an "overhead" of 3,500 bytes per record, although this would be a over-simplification. facts/events/links) would require this separation. Even something as simple as splitting each GEDCOM record into GEDCOM fragements (i.e. We have to break this link, if we are to make any change to the internal representation. Previously, it was just piped directly from the DB to the file, bypassing the application. The reason for the change over previous versions is that all data is now wrapped in an object. ![]() Caching helps performance (sometimes!), but obviously requires storage to do so. We could also review the amount of data we cache with each object. Moving this will reduce the size of the objects (and hence the overhead), to an extent. Many of the "genealogical record" objects have a lot of code/data that really belongs in their associated controllers. You could view this as an "overhead" of 3,500 bytes per record, although this would be a over-simplifica tion. So, we are using 64,000,000 / 16,000 = 4,000 bytes per record (internally) for data that has an external representation of 500 bytes. This 8mb file contains approximately 16,000 records, with approximately 500 bytes in each. As an approximate figure, 16mb is required for application overhead - which leaves 64mb for the internal representation of the data.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |