Re: django-phpBB3
Verfasst: Mittwoch 29. August 2012, 17:42
@jens: Soll das heissen ganz normale Klarnamen können nicht als Benutzernamen verwendet werden wenn sie etwas ausserhalb von ASCII enthalten‽
Das deutsche Python-Forum
Seit 2002 Diskussionen rund um die Programmiersprache Python
https://www.python-forum.de/
django-phpBB3
Seite 3 von 4
Re: django-phpBB3
Verfasst: Mittwoch 29. August 2012, 23:40
Das würde ich aber als Bug sehen. Spaces und Unicode im Namen sollte auf jeden Fall erlaubt sein, ist ja nicht mehr 1992.
Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 07:54
Würde ich nicht machen, dann gibts plötzlich 4 mal Leonidas, komplettes utf-8 in den Namen erlaubt zu viele gleiche Namen die mit freiem Auge nicht unterscheidbar sind (ich sag nur mal zero width whitespace in einem NamenLeonidas hat geschrieben:Das würde ich aber als Bug sehen. Spaces und Unicode im Namen sollte auf jeden Fall erlaubt sein, ist ja nicht mehr 1992.
)Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 07:59
@apollo13: Andererseits ist es auch wirklich blöd wenn jemand einen Umlaut oder ähnliches im Namen hat und den nicht verwenden darf. Ich denke dem Problem mit den gleich aussehenden Namen kann man mit einer Forumsregel entgegen wirken, dass es nicht erlaubt ist Namen so zu wählen, dass sie nicht von vorhandenen Namen unterscheidbar sind. Wer's trotzdem macht, wird aufgefordert den Namen zu ändern oder fliegt raus. Ich glaube nicht, dass das in der Praxis zu einem Massenphänomen oder Problem wird.
Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 08:36
@apollo13 Dafür brauche ich kein Unicode, apollol3
Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 09:39
Die Limitierung Nur alphanumerische Zeichen (Buchstaben, Ziffern und @/./+/-/_) sind erlaubt. kommt von Django, siehe auch: https://docs.djangoproject.com/en/1.4/t ... r.username
Ich vermute mal, es ist außerdem nur in den Forms limitiert:
Somit sollte es leicht möglich sein, mit einer eigenen Form und dem dazu gehörigen views die Limitierung selbst zu gestalten. Aber ich denke nicht das es wirklich Sinnvoll ist.
Ich vermute mal, es ist außerdem nur in den Forms limitiert:
Code: Alles auswählen
username = forms.RegexField(label=_("Username"), max_length=30,
regex=r'^[\w.@+-]+$',
help_text = _("Required. 30 characters or fewer. Letters, digits and "
"@/./+/-/_ only."),
error_messages = {
'invalid': _("This value may contain only letters, numbers and "
"@/./+/-/_ characters.")})Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 10:09
@jens Ich fände es durchaus sinnvoll, wenn ein Benutzer seinen echten Namen ohne Einschränkungen eintippen könnte, also insbesondere auch mit Leerzeichen zwischen Vor- und Nachnamen 
Und ich fände es lustig, wenn Benutzer Unicode-Symbole in ihren Namen verwenden könnten... warum auch nicht? Diese Einschränkung ist doch künstlich, und ich sehe keinen immanenten Grund dazu.
Und ich fände es lustig, wenn Benutzer Unicode-Symbole in ihren Namen verwenden könnten... warum auch nicht? Diese Einschränkung ist doch künstlich, und ich sehe keinen immanenten Grund dazu.Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 10:36
Siehe dazu auch http://stackoverflow.com/questions/1218 ... -usernames.jens hat geschrieben:Ich vermute mal, es ist außerdem nur in den Forms limitiert:
Re: django-phpBB3
Verfasst: Donnerstag 30. August 2012, 12:38
Naja, man kann auch ein Display-Name-Feld haben. Username ist E-Mail-Adresse, wie das so häufig im Internet anzutreffen ist und Anzeigename ist dann der entsprechende Nickname.
Re: django-phpBB3
Verfasst: Dienstag 18. September 2012, 10:36
Das stimmt:/me hat geschrieben:Siehe dazu auch http://stackoverflow.com/questions/1218 ... -usernames.jens hat geschrieben:Ich vermute mal, es ist außerdem nur in den Forms limitiert:
Also eigentlich wird es nur beim User erstellen limitiert, wenn man es mit dem Standard django forms macht.It is really not a problem - because this character restriction is in UserCreationForm (or RegistrationForm in django-registration) only as I remember, and you can easily make your own since field in database is just normal TextField.
Re: django-phpBB3
Verfasst: Dienstag 18. September 2012, 13:17
Bin auf ein neues Problem bei der migration gestoßen. Dank pudb weiß ich jetzt warum:
Hier im Forum konnte man als "Gast" posten. Eines der ersten Threads wurde als Gast anscheinend als Gast gestartet. Komisch ist, wenn man sich: http://www.python-forum.de/viewtopic.php?t=9 ansieht, sind alle User dort noch vorhanden. Doch in der Übersicht: http://www.python-forum.de/viewforum.php?f=5&start=1550 (Letzte Seite von "Offtopic") sieht man in der Spalte Autor "Gast", mit Link zu http://www.python-forum.de/memberlist.p ... rofile&u=7 (Ein User mit ID 7)
In der DB ist topic.poster_id == 7
Allerdings gibt es keinen User mit ID 7... Es gibt eine Lücke zwischen ID 6 und 10
Die Frage ist nun: Ist das nur beim pseudo User "Gast" der Fall, oder gibt es generell "Lücken" wenn man User löscht?
Als work-a-round fällt mir jetzt nur ein, alle nicht existierenden User auf "Anonymous" zu mappen. Das ist ein pseudo User Account von phpBB. (Wobei ich denke das eigentlich Gast == Anonymous sein sollte. Sind anscheinend aber zwei verschiedene Accounts?)
EDIT: So oft kommt es anscheinend nicht vor:
Hier im Forum konnte man als "Gast" posten. Eines der ersten Threads wurde als Gast anscheinend als Gast gestartet. Komisch ist, wenn man sich: http://www.python-forum.de/viewtopic.php?t=9 ansieht, sind alle User dort noch vorhanden. Doch in der Übersicht: http://www.python-forum.de/viewforum.php?f=5&start=1550 (Letzte Seite von "Offtopic") sieht man in der Spalte Autor "Gast", mit Link zu http://www.python-forum.de/memberlist.p ... rofile&u=7 (Ein User mit ID 7)
In der DB ist topic.poster_id == 7
Allerdings gibt es keinen User mit ID 7... Es gibt eine Lücke zwischen ID 6 und 10
Die Frage ist nun: Ist das nur beim pseudo User "Gast" der Fall, oder gibt es generell "Lücken" wenn man User löscht?
Als work-a-round fällt mir jetzt nur ein, alle nicht existierenden User auf "Anonymous" zu mappen. Das ist ein pseudo User Account von phpBB. (Wobei ich denke das eigentlich Gast == Anonymous sein sollte. Sind anscheinend aber zwei verschiedene Accounts?)
EDIT: So oft kommt es anscheinend nicht vor:
Code: Alles auswählen
*** Migrate phpBB topic entries...
get topic watch information...OK
topic 9 poster: phpBB User with ID 7 doesn't exist. Use Anonymous.
topic 54 poster: phpBB User with ID 4 doesn't exist. Use Anonymous.
topic 182 poster: phpBB User with ID 3 doesn't exist. Use Anonymous.
topic 185 poster: phpBB User with ID 3 doesn't exist. Use Anonymous.
topic 188 poster: phpBB User with ID 3 doesn't exist. Use Anonymous.
topic 229 poster: phpBB User with ID 4 doesn't exist. Use Anonymous.
topic 250 poster: phpBB User with ID 4 doesn't exist. Use Anonymous.
topic 291 poster: phpBB User with ID 4 doesn't exist. Use Anonymous.
topic 402 poster: phpBB User with ID 3 doesn't exist. Use Anonymous.
topic 410 poster: phpBB User with ID 4 doesn't exist. Use Anonymous.
topic 1077 poster: phpBB User with ID 4 doesn't exist. Use Anonymous.
topic 8405 poster: phpBB User with ID 3510 doesn't exist. Use Anonymous.
topic 8407 poster: phpBB User with ID 3467 doesn't exist. Use Anonymous.
*** 27459 topics migrated in 36.0 min (rate: 12.7/sec)
Re: django-phpBB3
Verfasst: Dienstag 18. September 2012, 20:21
Django 1.5 behebt die Probleme so oder soLeonidas hat geschrieben:Naja, man kann auch ein Display-Name-Feld haben. Username ist E-Mail-Adresse, wie das so häufig im Internet anzutreffen ist und Anzeigename ist dann der entsprechende Nickname.
Siehe: https://github.com/django/django/pull/370 (Teile von Inyoka laufen schon darauf, also funktioniert der Patch auch bereits relativ gut )Re: django-phpBB3
Verfasst: Dienstag 18. September 2012, 20:57
Das ist gut. Hatte mich eh dazu entschlossen den Usernamen nicht zu verändern.
Nun scheint die Migration auch mit den Dump vom Forum hier zu laufen. Allerdings könnte man sich nochmal ansehen, ob man es noch optimieren kann.
Während die 27.500 topics mit ca. 150/sek in 3Min migriert werden, geht es bei den eigentlichen posts auf dem selben Maschine mit nur mageren 7/sek zu... Bei rund 220.000 Posts dauert das also einige Stunden. Wobei macht man ja nur einmal. Wäre also was für einen "über die nacht" Job.
Kann mir vorstellen, das u.a. das säubern des bbcode eine weile dauert. Außerdem wird jeweils die HTML Version generiert.
Nun scheint die Migration auch mit den Dump vom Forum hier zu laufen. Allerdings könnte man sich nochmal ansehen, ob man es noch optimieren kann.
Während die 27.500 topics mit ca. 150/sek in 3Min migriert werden, geht es bei den eigentlichen posts auf dem selben Maschine mit nur mageren 7/sek zu... Bei rund 220.000 Posts dauert das also einige Stunden. Wobei macht man ja nur einmal. Wäre also was für einen "über die nacht" Job.
Kann mir vorstellen, das u.a. das säubern des bbcode eine weile dauert. Außerdem wird jeweils die HTML Version generiert.
Re: django-phpBB3
Verfasst: Dienstag 18. September 2012, 23:03
Warum dauert das denn so lang? Schon mal den Profiler angeworfen? Ist ja nicht so dass 220.000 Posts jetzt so eine riesige Datenmenge wären, mein DB-Dump in SQLite (ohne diese Cache-Tabellen die phpBB anlegt) ist jetzt nur 68MB groß.
Re: django-phpBB3
Verfasst: Donnerstag 20. September 2012, 10:12
Hast du Links für mich zum Thema Profiling? Hab ich bisher noch nie gemacht.
Neue Problem: https://github.com/jedie/django-phpBB3/issues/13
Wegen dem hier: http://www.python-forum.de/viewtopic.php?p=13202#p13202 Dort kommt im code das vor:
Also eigentlich ist es &mymodify;
Das ist glaube ich ein Bug in phpBB, siehe auch: http://www.python-forum.de/viewtopic.php?f=10&t=22855
Hab dazu ein work-a-round comittet: https://github.com/jedie/django-phpBB3/ ... 5516be7f34
Weiß allerdings nicht ob das jetzt die Beste Lösung ist.
Man müßte wohl nachsehen, wo ein &bla; vorkommt. Ob es im Text oder im code-Block ist.
Neue Problem: https://github.com/jedie/django-phpBB3/issues/13
Wegen dem hier: http://www.python-forum.de/viewtopic.php?p=13202#p13202 Dort kommt im code das vor:
Code: Alles auswählen
c->modify = &mymodify;Das ist glaube ich ein Bug in phpBB, siehe auch: http://www.python-forum.de/viewtopic.php?f=10&t=22855
Hab dazu ein work-a-round comittet: https://github.com/jedie/django-phpBB3/ ... 5516be7f34
Weiß allerdings nicht ob das jetzt die Beste Lösung ist.
Man müßte wohl nachsehen, wo ein &bla; vorkommt. Ob es im Text oder im code-Block ist.
Re: django-phpBB3
Verfasst: Donnerstag 20. September 2012, 10:35
Zum Thema Profiling, schau dir doch die Dokumentation das Python-Profilers cProfile an.
Re: django-phpBB3
Verfasst: Donnerstag 20. September 2012, 12:22
Ja, das mache ich gerade, so:Leonidas hat geschrieben:Zum Thema Profiling, schau dir doch die Dokumentation das Python-Profilers cProfile an.
Code: Alles auswählen
phpBB2DjangoBB_project$ python -m cProfile -s cumulative manage.py phpbb2djangobb --flush_djangobb > stats.txtMal sehen was raus kommt.
Re: django-phpBB3
Verfasst: Donnerstag 20. September 2012, 14:28
Alles ab cumtime > 10 mit einem zusammen-gelöschtem Datensatz:
Anscheinend baut whoosh auch gleich den Suchindex auf. Das könnte man sich eigentlich erst mal sparen. Zumal whoosh produktiv am besten von einem anderen backend ersetzt wird.
Die Geschichte um bbcode-cleanup scheint vergleichsweise schnell zu sehen:
Code: Alles auswählen
...
*** 202 topics migrated in 13.0 sec (rate: 15.6/sec)
...
*** 1024 posts migrated in 10.0 min (rate: 1.7/sec)
...
116963147 function calls (115264047 primitive calls) in 629.339 seconds
Ordered by: cumulative time
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 629.340 629.340 manage.py:2(<module>)
1 0.000 0.000 629.277 629.277 __init__.py:438(execute_from_command_line)
1 0.000 0.000 629.277 629.277 __init__.py:340(execute)
1 0.000 0.000 628.171 628.171 base.py:187(run_from_argv)
1 0.000 0.000 628.169 628.169 base.py:198(execute)
1 0.000 0.000 627.116 627.116 phpbb2djangobb.py:99(handle)
1 0.007 0.007 627.116 627.116 phpbb2djangobb.py:108(_handle)
1 0.102 0.102 600.181 600.181 phpbb2djangobb.py:554(migrate_posts)
1225 0.040 0.000 596.343 0.487 manager.py:136(create)
1225 0.028 0.000 596.142 0.487 query.py:370(create)
1023 0.039 0.000 591.749 0.578 models.py:219(save)
1665 0.018 0.000 590.419 0.355 base.py:452(save)
1665 0.136 0.000 590.401 0.355 base.py:467(save_base)
16645/12553 0.119 0.000 557.543 0.044 dispatcher.py:149(send)
1023 0.184 0.000 557.198 0.545 indexes.py:194(update_object)
1023 0.082 0.000 557.004 0.544 whoosh_backend.py:167(update)
1023 0.012 0.000 477.258 0.467 writing.py:460(commit)
1023 0.055 0.000 477.246 0.467 filewriting.py:471(commit)
1023 0.049 0.000 239.220 0.234 filewriting.py:420(_merge_segments)
1023 0.119 0.000 239.171 0.234 filewriting.py:52(MERGE_SMALL)
1023 0.023 0.000 233.680 0.228 filewriting.py:322(add_reader)
1023 2.728 0.003 227.074 0.222 filewriting.py:314(_merge_fields)
1023 0.022 0.000 214.986 0.210 filewriting.py:434(_flush_segment)
1023 6.380 0.006 214.714 0.210 base.py:122(add_postings)
594686 2.748 0.000 212.403 0.000 filewriting.py:120(renumber_postings)
594686 11.993 0.000 209.655 0.000 reading.py:334(iter_postings)
323372 9.872 0.000 161.101 0.000 whoosh2.py:332(finish_term)
347323 4.277 0.000 149.246 0.000 filereading.py:253(postings)
347323 4.046 0.000 138.951 0.000 whoosh2.py:518(matcher)
323780 3.511 0.000 83.389 0.000 whoosh2.py:283(_write_block)
347323 3.574 0.000 68.475 0.000 filetables.py:500(__getitem__)
340407 5.655 0.000 65.744 0.000 whoosh2.py:383(__init__)
323780 14.767 0.000 60.635 0.000 whoosh2.py:977(to_file)
1023 0.010 0.000 58.628 0.057 writing.py:448(update_document)
1023 0.391 0.000 58.618 0.057 writing.py:424(_record)
1023 0.046 0.000 58.223 0.057 writing.py:294(update_document)
680720 3.664 0.000 55.225 0.000 whoosh2.py:421(_next_block)
323372 3.185 0.000 51.022 0.000 filetables.py:489(add)
9515 0.543 0.000 47.780 0.005 filereading.py:47(__init__)
1023 0.023 0.000 44.366 0.043 writing.py:164(searcher)
1023 0.024 0.000 43.054 0.042 filewriting.py:236(reader)
1023 0.059 0.000 43.027 0.042 fileindex.py:280(_reader)
8492 0.092 0.000 42.870 0.005 fileindex.py:302(segreader)
347323 2.555 0.000 42.193 0.000 filetables.py:247(__getitem__)
687730 4.281 0.000 39.637 0.000 filetables.py:257(all)
9951309/8590811 22.537 0.000 38.633 0.000 {len}
9515 0.119 0.000 35.230 0.004 whoosh2.py:81(terms_reader)
340952 2.570 0.000 34.573 0.000 whoosh2.py:410(_read_block)
9515 0.233 0.000 32.659 0.003 whoosh2.py:497(__init__)
9515 0.058 0.000 32.151 0.003 filetables.py:497(__init__)
9515 0.167 0.000 32.093 0.003 filetables.py:374(__init__)
687730 10.470 0.000 31.786 0.000 filetables.py:284(ranges_for_key)
9515 15.358 0.002 31.729 0.003 filetables.py:174(__init__)
340952 13.749 0.000 31.289 0.000 whoosh2.py:997(from_file)
323372 1.568 0.000 28.919 0.000 filetables.py:121(add)
340493 2.557 0.000 28.128 0.000 filereading.py:177(<genexpr>)
323372 11.940 0.000 27.352 0.000 filetables.py:330(add_all)
1931 0.018 0.000 26.902 0.014 __init__.py:48(_commit)
1931 26.885 0.014 26.885 0.014 {method 'commit' of '_mysql.connection' objects}
1665 0.021 0.000 24.418 0.015 transaction.py:113(commit_unless_managed)
1665 0.032 0.000 24.375 0.015 __init__.py:197(commit_unless_managed)
340493 2.298 0.000 22.983 0.000 filetables.py:528(keys)
2122926 13.627 0.000 22.812 0.000 filetables.py:211(read)
669658 4.756 0.000 22.646 0.000 whoosh2.py:322(add)
3458 0.078 0.000 20.540 0.006 query.py:353(get)
323372 3.052 0.000 20.101 0.000 whoosh2.py:313(start_term)
1023 0.031 0.000 17.791 0.017 indexes.py:155(full_prepare)
1023 0.087 0.000 17.737 0.017 indexes.py:133(prepare)
6138 0.108 0.000 17.476 0.003 fields.py:67(prepare)
4092 0.039 0.000 17.417 0.004 fields.py:152(prepare)
340952 2.456 0.000 16.987 0.000 whoosh2.py:416(_consume_block)
1023 0.023 0.000 16.835 0.016 filewriting.py:439(_close_segment)
340407 2.512 0.000 16.728 0.000 whoosh2.py:548(valuedecoder)
1119837/1074825 2.918 0.000 16.496 0.000 {hasattr}
1023 0.013 0.000 15.425 0.015 whoosh2.py:373(close)
1023 0.805 0.001 15.392 0.015 whoosh2.py:482(close)
323372 1.483 0.000 14.691 0.000 whoosh2.py:479(valuecoder)
323780 6.538 0.000 14.479 0.000 base.py:461(add_block)
13090 0.724 0.000 14.304 0.001 query.py:235(clone)
15420 0.152 0.000 14.272 0.001 related.py:331(__get__)
6563990 14.246 0.000 14.246 0.000 {method 'read' of 'cStringIO.StringI' objects}
323372 4.006 0.000 14.046 0.000 whoosh2.py:289(_start_blocklist)
340407 6.576 0.000 13.544 0.000 base.py:507(from_string)
669658 8.147 0.000 13.411 0.000 filewriting.py:97(add)
1 0.021 0.021 13.269 13.269 phpbb2djangobb.py:468(migrate_topic)
323372 5.741 0.000 13.208 0.000 base.py:477(to_string)
340493 2.197 0.000 12.944 0.000 filetables.py:237(keys)
12059 0.174 0.000 12.917 0.001 query.py:853(_clone)
4868208 12.803 0.000 12.803 0.000 {method 'write' of 'file' objects}
5375697 12.716 0.000 12.716 0.000 {method 'unpack' of 'Struct' objects}
251017/52360 3.970 0.000 12.450 0.000 copy.py:145(deepcopy)
2046 0.023 0.000 12.272 0.006 util.py:159(feed)
4092 1.795 0.000 12.229 0.003 HTMLParser.py:140(goahead)
2046 0.012 0.000 12.226 0.006 HTMLParser.py:107(feed)
323780 4.239 0.000 12.081 0.000 base.py:767(minimize_ids)
8559 0.268 0.000 12.041 0.001 query.py:231(iterator)
5938888 12.003 0.000 12.003 0.000 {method 'append' of 'list' objects}
340952 3.343 0.000 11.838 0.000 whoosh2.py:1014(read_ids)
974616 6.490 0.000 11.543 0.000 structfile.py:231(write_uint)
1023 0.022 0.000 11.467 0.011 util.py:216(convert_text_to_html)
4782 0.118 0.000 11.355 0.002 compiler.py:794(execute_sql)
1023 0.648 0.001 11.047 0.011 filewriting.py:342(add_document)
3477 0.073 0.000 10.747 0.003 query.py:77(__len__)
670695 6.011 0.000 10.617 0.000 filetables.py:52(md5_hash)
8672 0.178 0.000 10.591 0.001 compiler.py:751(results_iter)
669658 6.250 0.000 10.462 0.000 base.py:746(add)
...
1052 0.020 0.000 0.316 0.000 utils.py:112(clean_bbcode)
...
1052 0.013 0.000 0.146 0.000 utils.py:102(phpbb_html2bbcode)
...
1254 0.009 0.000 0.142 0.000 utils.py:85(replace_all)
...
2046 0.027 0.000 0.061 0.000 utils.py:87(replace_entity)
...
Die Geschichte um bbcode-cleanup scheint vergleichsweise schnell zu sehen:
Re: django-phpBB3
Verfasst: Donnerstag 20. September 2012, 14:40
Ha, das ist es! Mit https://github.com/jedie/django-phpBB3/ ... 47b7029b66 also ohne search index, sieht das schon viel besser aus 21.1/sec statt nur 1.7/sec !jens hat geschrieben:Alles ab cumtime > 10 mit einem zusammen-gelöschtem Datensatz:Anscheinend baut whoosh auch gleich den Suchindex auf.Code: Alles auswählen
... *** 202 topics migrated in 13.0 sec (rate: 15.6/sec) ... *** 1024 posts migrated in 10.0 min (rate: 1.7/sec) ... 116963147 function calls (115264047 primitive calls) in 629.339 seconds
Selbe Liste mit cumtime>5 :
Code: Alles auswählen
...
*** 202 topics migrated in 13.6 sec (rate: 14.8/sec)
...
*** 1024 posts migrated in 48.5 sec (rate: 21.1/sec)
...
7474957 function calls (7292772 primitive calls) in 76.392 seconds
Ordered by: cumulative time
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 76.393 76.393 manage.py:2(<module>)
1 0.000 0.000 76.329 76.329 __init__.py:438(execute_from_command_line)
1 0.000 0.000 76.329 76.329 __init__.py:340(execute)
1 0.000 0.000 74.539 74.539 base.py:187(run_from_argv)
1 0.000 0.000 74.536 74.536 base.py:198(execute)
1 0.000 0.000 74.385 74.385 phpbb2djangobb.py:101(handle)
1 0.008 0.008 74.385 74.385 phpbb2djangobb.py:110(_handle)
1 0.087 0.087 47.761 47.761 phpbb2djangobb.py:561(migrate_posts)
1225 0.038 0.000 43.821 0.036 manager.py:136(create)
1225 0.027 0.000 43.620 0.036 query.py:370(create)
1023 0.039 0.000 39.232 0.038 models.py:219(save)
1665 0.019 0.000 38.441 0.023 base.py:452(save)
1665 0.136 0.000 38.422 0.023 base.py:467(save_base)
1925 0.018 0.000 31.615 0.016 __init__.py:48(_commit)
1925 31.597 0.016 31.597 0.016 {method 'commit' of '_mysql.connection' objects}
1665 0.020 0.000 29.653 0.018 transaction.py:113(commit_unless_managed)
1665 0.033 0.000 29.611 0.018 __init__.py:197(commit_unless_managed)
1 0.024 0.024 13.442 13.442 phpbb2djangobb.py:475(migrate_topic)
2046 0.023 0.000 12.089 0.006 util.py:159(feed)
4092 1.760 0.000 12.048 0.003 HTMLParser.py:140(goahead)
2046 0.013 0.000 12.047 0.006 HTMLParser.py:107(feed)
1023 0.021 0.000 11.367 0.011 util.py:216(convert_text_to_html)
1 0.017 0.017 9.449 9.449 phpbb2djangobb.py:674(update_topic_stats)
1412 0.032 0.000 9.049 0.006 query.py:353(get)
6938 0.389 0.000 7.880 0.001 query.py:235(clone)
2723 0.066 0.000 7.142 0.003 compiler.py:794(execute_sql)
138319/27752 2.193 0.000 6.891 0.000 copy.py:145(deepcopy)
1023 0.015 0.000 6.586 0.006 util.py:164(urlize)
1026 0.028 0.000 6.536 0.006 manager.py:130(get)
4432 0.136 0.000 6.458 0.001 query.py:231(iterator)
5913 0.087 0.000 6.361 0.001 query.py:853(_clone)
4545 0.085 0.000 5.633 0.001 compiler.py:751(results_iter)
1023 0.013 0.000 5.605 0.005 util.py:182(smiles)
184769/165458 0.378 0.000 5.437 0.000 {len}
1431 0.031 0.000 5.142 0.004 query.py:77(__len__)
...Was könnte man da noch optimieren???
EDIT2: So, nun sind auf dem produktiv Server rund 100 posts / sec drin. (Lokal bei mir greift eine VM mit dem Migrationsskript auf den MySQL Server in einer anderen VM zu. Deswegen nur 21.1/sec
In der Praxis bedeutet das, die Migration ist in ca. 30Min fertig, statt vorher in 8h
Re: django-phpBB3
Verfasst: Donnerstag 20. September 2012, 15:42
Nächstes Problem:
bei: http://www.python-forum.de/viewtopic.php?p=74377#p74377
Code: Alles auswählen
File "/home/jedie/DjangoBB_env/src/django-phpbb3/django_phpBB3/management/commands/phpbb2djangobb.py", line 610, in migrate_posts
user_ip=phpbb_post.poster_ip,
File "/home/jedie/DjangoBB_env/lib/python2.6/site-packages/django/db/models/manager.py", line 137, in create
return self.get_query_set().create(**kwargs)
File "/home/jedie/DjangoBB_env/lib/python2.6/site-packages/django/db/models/query.py", line 377, in create
obj.save(force_insert=True, using=self.db)
File "/home/jedie/DjangoBB_env/src/djangobb/djangobb_forum/models.py", line 222, in save
self.body_html = smiles(self.body_html)
File "/home/jedie/DjangoBB_env/src/djangobb/djangobb_forum/util.py", line 188, in smiles
parser.feed(data)
File "/home/jedie/DjangoBB_env/src/djangobb/djangobb_forum/util.py", line 160, in feed
HTMLParser.feed(self, data)
File "/usr/lib64/python2.6/HTMLParser.py", line 108, in feed
self.goahead(0)
File "/usr/lib64/python2.6/HTMLParser.py", line 148, in goahead
k = self.parse_starttag(i)
File "/usr/lib64/python2.6/HTMLParser.py", line 229, in parse_starttag
endpos = self.check_for_whole_start_tag(i)
File "/usr/lib64/python2.6/HTMLParser.py", line 304, in check_for_whole_start_tag
self.error("malformed start tag")
File "/usr/lib64/python2.6/HTMLParser.py", line 115, in error
raise HTMLParseError(message, self.getpos())
HTMLParseError: malformed start tag, at line 1, column 155