[Zeitgeist] [Bug 642898] Re: Upgrading database scheme is broken for newly created databases
revno: 1595 fixes bug(s): https://launchpad.net/bugs/642898 committer: Markus Korn thek...@gmx.de branch nick: trunk timestamp: Mon 2010-09-20 09:29:32 +0200 message: always create core schema for new databases (LP: #642898) ** Changed in: zeitgeist Status: In Progress = Fix Committed -- Upgrading database scheme is broken for newly created databases https://bugs.launchpad.net/bugs/642898 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: Fix Committed Bug description: Todays newly created database version 2 broke the upgrade path, we have no upgrade script for 0 (which means 'no version entry found') to 2. This happens because no-existing databases do not have such table. $ ZEITGEIST_DATABASE_PATH=/tmp/dfgdsfsddf ./zeitgeist-daemon :( DEBUG:root:Checking for another running instance... DEBUG:root:No running instances found. INFO:zeitgeist.sql:Using database: /tmp/dfgdsfsddf DEBUG:zeitgeist.sql:Schema 'core' not found: no such table: schema_version INFO:zeitgeist.sql:Upgrading database 'core' from version 0 to 2. This may take a while CRITICAL:zeitgeist.sql:Failed to upgrade database 'core' from version 0 to 2: No module named core_0_2 We have to check if we are operating on a new database. (Side note: we need tests for upgrades) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.1
Hello Zeitgeist Framework Team, On 2010-09-20 07:35z (just requested), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.1 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Translation template import - zeitgeist in Zeitgeist Framework 0.5
Hello Zeitgeist Framework Team, On 2010-09-20 07:35z (just requested), you uploaded a translation template for zeitgeist in Zeitgeist Framework 0.5 in Launchpad. The template has now been imported successfully. Thank you, The Launchpad team ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 642898] Re: Upgrading database scheme is broken for newly created databases
** Branch linked: lp:zeitgeist -- Upgrading database scheme is broken for newly created databases https://bugs.launchpad.net/bugs/642898 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: Fix Committed Bug description: Todays newly created database version 2 broke the upgrade path, we have no upgrade script for 0 (which means 'no version entry found') to 2. This happens because no-existing databases do not have such table. $ ZEITGEIST_DATABASE_PATH=/tmp/dfgdsfsddf ./zeitgeist-daemon :( DEBUG:root:Checking for another running instance... DEBUG:root:No running instances found. INFO:zeitgeist.sql:Using database: /tmp/dfgdsfsddf DEBUG:zeitgeist.sql:Schema 'core' not found: no such table: schema_version INFO:zeitgeist.sql:Upgrading database 'core' from version 0 to 2. This may take a while CRITICAL:zeitgeist.sql:Failed to upgrade database 'core' from version 0 to 2: No module named core_0_2 We have to check if we are operating on a new database. (Side note: we need tests for upgrades) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 643303] [NEW] Upgrade of the db schema strategy for version jumps
Public bug reported: We have to discuss how to support versions jump in the upgrade path of our db schema, like from (core, 0) to (core, 2). This becomes even more important when we reach the next version. For me there are two solution: 1.) write 'dummy' upgrade scripts, like core_0_2.py, which do not more than running core_0_1.run() and core_1_2.run() one after another 2.) add some magic to sql._do_schema_upgrade() which automatically tries to find an upgrade path and run the 'shortest' possible one. There is an issue with both solutions: right now the upgrade mechanism is designed in a way that after each data upgrade the schema upgrade is done. In both solutions the schema upgrade will be done *after* the full upgrade path. This can be handled by solution 1.) in the sanest possible way, the downside is that 1.) does not scale well for big numbers of schema versions around. Any Ideas? ** Affects: zeitgeist Importance: Medium Status: New ** Changed in: zeitgeist Importance: Undecided = Medium -- Upgrade of the db schema strategy for version jumps https://bugs.launchpad.net/bugs/643303 You received this bug notification because you are a member of Zeitgeist Framework Team, which is subscribed to Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: We have to discuss how to support versions jump in the upgrade path of our db schema, like from (core, 0) to (core, 2). This becomes even more important when we reach the next version. For me there are two solution: 1.) write 'dummy' upgrade scripts, like core_0_2.py, which do not more than running core_0_1.run() and core_1_2.run() one after another 2.) add some magic to sql._do_schema_upgrade() which automatically tries to find an upgrade path and run the 'shortest' possible one. There is an issue with both solutions: right now the upgrade mechanism is designed in a way that after each data upgrade the schema upgrade is done. In both solutions the schema upgrade will be done *after* the full upgrade path. This can be handled by solution 1.) in the sanest possible way, the downside is that 1.) does not scale well for big numbers of schema versions around. Any Ideas? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 397715] Re: I18N of zeitgeist
I discussed this issue with Siegfried yesterday, and I would like to bring the
overall translation workflow to everybody's attention again:
* We want to make our ontology 'symbols' translatable
* logging output should not be translated
* we might need translation support for tools in tools/
* we should not use lp:zeitgeist as the target branch for launchpad's
translation service, we should use another branch, and merge translations as
part of the release process.
Any further thoughts?
--
I18N of zeitgeist
https://bugs.launchpad.net/bugs/397715
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
Status in Zeitgeist Framework: Confirmed
Bug description:
zeitgeist is using gettext for I18N in various places, but its usage is
inconsistent. A quick grep with `grep -R -E [^\_]\_{1}\( .` shows we are
using gettext for:
- some logging messages
- the name and description of the FF DataProvider
- display name of Content and Source objects in our datamodel (real gettext
support is not implemented yet)
Thinking about this three items a bit I think none of them make sense at all.
Logging is for debugging purposes, in the future we will ask our user to add a
log file to a bugreport. If the logging messages are translated to a random
language we will hardly understand the content. Translating the display name of
Content and Source object also makes no sense, instead of this it should be
done by the client. This way one database can be accessed with different
language settings. And if we agree on the last two arguments, it also makes
less sense for the last item.
But just in case I'm missing the point here, and we decide to have I18N support
in zeitgeist we should decide which parts we would exactly like to translate,
and dig trough the code to add language support to related elements
consistently.
Markus
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
Re: [Zeitgeist] [Bug 397715] Re: I18N of zeitgeist
+1 the transaltions happening in trunk are annoying as hell
On Mon, Sep 20, 2010 at 9:57 AM, Markus Korn thek...@gmx.de wrote:
I discussed this issue with Siegfried yesterday, and I would like to bring
the overall translation workflow to everybody's attention again:
* We want to make our ontology 'symbols' translatable
* logging output should not be translated
* we might need translation support for tools in tools/
* we should not use lp:zeitgeist as the target branch for launchpad's
translation service, we should use another branch, and merge translations as
part of the release process.
Any further thoughts?
--
I18N of zeitgeist
https://bugs.launchpad.net/bugs/397715
You received this bug notification because you are subscribed to The
Zeitgeist Project.
Status in Zeitgeist Framework: Confirmed
Bug description:
zeitgeist is using gettext for I18N in various places, but its usage is
inconsistent. A quick grep with `grep -R -E [^\_]\_{1}\( .` shows we are
using gettext for:
- some logging messages
- the name and description of the FF DataProvider
- display name of Content and Source objects in our datamodel (real
gettext support is not implemented yet)
Thinking about this three items a bit I think none of them make sense at
all. Logging is for debugging purposes, in the future we will ask our user
to add a log file to a bugreport. If the logging messages are translated to
a random language we will hardly understand the content. Translating the
display name of Content and Source object also makes no sense, instead of
this it should be done by the client. This way one database can be accessed
with different language settings. And if we agree on the last two arguments,
it also makes less sense for the last item.
But just in case I'm missing the point here, and we decide to have I18N
support in zeitgeist we should decide which parts we would exactly like to
translate, and dig trough the code to add language support to related
elements consistently.
Markus
--
This is me doing some advertisement for my blog http://seilo.geekyogre.com
--
I18N of zeitgeist
https://bugs.launchpad.net/bugs/397715
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
Status in Zeitgeist Framework: Confirmed
Bug description:
zeitgeist is using gettext for I18N in various places, but its usage is
inconsistent. A quick grep with `grep -R -E [^\_]\_{1}\( .` shows we are
using gettext for:
- some logging messages
- the name and description of the FF DataProvider
- display name of Content and Source objects in our datamodel (real gettext
support is not implemented yet)
Thinking about this three items a bit I think none of them make sense at all.
Logging is for debugging purposes, in the future we will ask our user to add a
log file to a bugreport. If the logging messages are translated to a random
language we will hardly understand the content. Translating the display name of
Content and Source object also makes no sense, instead of this it should be
done by the client. This way one database can be accessed with different
language settings. And if we agree on the last two arguments, it also makes
less sense for the last item.
But just in case I'm missing the point here, and we decide to have I18N support
in zeitgeist we should decide which parts we would exactly like to translate,
and dig trough the code to add language support to related elements
consistently.
Markus
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
