incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject Re: [Apache Bloodhound] #288: Create prototype for legacy database schema proxy
Date Wed, 30 Jan 2013 05:32:09 GMT
#288: Create prototype for legacy database schema proxy
---------------------------+-----------------------------------
  Reporter:  jure          |      Owner:  jure
      Type:  enhancement   |     Status:  new
  Priority:  major         |  Milestone:
 Component:  multiproduct  |    Version:
Resolution:                |   Keywords:  bep-0003 multiproduct
---------------------------+-----------------------------------

Comment (by olemis):

 I'd like to propose some features related to #288 for you to consider .
 These are aimed at succeeding with tests cases for permissions , and
 ticket API . I've ben working the last few days towards that goal . The
 proposal is presented in the form of two patches .
 [attachment:t288_r1438538_sql_translate_global_env.diff The first one]
 incorporates the following features :

   1. Add a context manager for switching product environments
      with the goal in mind of better tracking of active environment
      when using nested transactions . JFTR notice that «active
 environment»
      is stored in TLS .
   2. Add two methods `db_direct_query` and `db_direct_transaction`
      providing direct DB access (i.e. no product prefix translation).
   3. Default product prefix will be '' rather than 'default' and will
      be reserved for global environment (i.e. `trac.env.Environment`).
   4. `ProductEnvironment(env, None) is env` and
      `ProductEnvironment(env, '') is env` in order to be consistent with
      (3) above.

 Up to this point patch order is as follows ...

 {{{
 #!sh

 $ hg qapplied
 t288/t288_r1438538_sql_translate_global_env.diff
 t355/t355_r1437383_trac_test_perm.diff
 t355/t355_r1437383_trac_test_ticket_api.diff

 }}}

 ... and everything is still looking ok and all tests (except those in
 tests.perm and tests.ticket.api) succeed . The next logical step forward
 is to implement the actual translation for the global environment with the
 help of (1) and (2) above.

 In the mechanism mentioned in (2) both , aforementioned context manager
 and TLS variable participate following the following sequence

   * context manager sets env in TLS
   * iterable cursor checks env var in TLS .
     - if set to product env , translate SQL considering product = prefix
     - if set to global env , translate SQL considering product = ''
     - if set to `None` (e.g. after invoking `db_direct_query`
       and `db_direct_transaction` ) then do not translate SQL
       query.

 ... at least that's the idea I tried to sketch in
 [attachment:t288_r1438538_sql_translate_global_env_pending.diff the second
 patch] , but up to that point tests won't work anymore  :'(

 When patches applied this way

 {{{
 #!sh

 $ hg qapplied
 t288/t288_r1438538_sql_translate_global_env.diff
 t288/t288_r1438538_sql_translate_global_env_pending.diff
 t355/t355_r1437383_trac_test_perm.diff
 t355/t355_r1437383_trac_test_ticket_api.diff

 }}}

 ... this is what I get :

 {{{
 #!sh

 $ python setup.py test -m tests.env
 [...]
 Testing env.get_known_users ... ERROR
 Testing env.get_version ... ERROR
 Testing env.__getattr__ ... ok
 Testing env.is_component_enabled ... ok
 Testing env.path ... ok
 Testing env.__init__ ... ok

 ======================================================================
 ERROR: Testing env.get_known_users
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/path/to/bloodhound/bloodhound_multiproduct/tests/env.py", line
 182, in setUp
     EnvironmentTestCase.setUp(self)
   File "/path/to/bloodhound/trac/trac/tests/env.py", line 16, in setUp
     self.env = Environment(env_path, create=True)
   File "/path/to/bloodhound/trac/trac/core.py", line 140, in __call__
     self.__init__(*args, **kwargs)
   File "/path/to/bloodhound/trac/trac/core.py", line 107, in new_init
     original_init(self, *args, **kwargs)
   File "/path/to/bloodhound/bloodhound_multiproduct/multiproduct/env.py",
 line 54, in __init__
     super(Environment, self).__init__(path, create=create,
 options=options)
   File "/path/to/bloodhound/trac/trac/core.py", line 107, in new_init
     original_init(self, *args, **kwargs)
   File "/path/to/bloodhound/trac/trac/env.py", line 289, in __init__
     setup_participant.environment_created()
   File "/path/to/bloodhound/trac/trac/env.py", line 743, in
 environment_created
     vals)
   File "/path/to/bloodhound/trac/trac/db/util.py", line 139, in
 executemany
     cursor.executemany(query, params)
   File
 "/path/to/bloodhound/bloodhound_multiproduct/multiproduct/dbcursor.py",
 line 79, in executemany
     return super(BloodhoundIterableCursor,
 self).executemany(self._translate_sql(sql), args=args)
   File "/path/to/bloodhound/trac/trac/db/util.py", line 85, in executemany
     return self.cursor.executemany(sql_escape_percent(sql), args)
   File "/path/to/bloodhound/trac/trac/db/sqlite_backend.py", line 62, in
 executemany
     args)
   File "/path/to/bloodhound/trac/trac/db/sqlite_backend.py", line 48, in
 _rollback_on_error
     return function(self, *args, **kwargs)
 OperationalError: table component has no column named product

 [...]

 }}}

 So I guess something in there is breaking multi-product upgrades . It
 seems to be related to the translation of CREATE and/or ALTER statements ,
 but I'm not 100% sure . Anyway ...

 @jure : could you please take a look and review ?

 I'll continue trying to figure out what else needs to be done , hoping
 I'll find the root cause , but I share the code soon looking forward to
 your feedback .

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/288#comment:18>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

Mime
View raw message