Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Changes between Initial Version and Version 1 of Ticket #1860


Ignore:
Timestamp:
08/22/08 11:50:15 (11 years ago)
Author:
Chris Arndt
Comment:

I'm having big troubles understanding the exact intention of this ticket. I tried to clean up the description a bit (language and formatting) but it is still confusing. Can you please give a bit more background information on what you are trying to achieve and how this patch would benefit TurboGears?

I think, for changes of this dimension it is best to discuss your changes on the trunk mailing list first and maybe even create a branch to test this out. If we are to support yet another ORM, this has major implications on documentation, support in other parts of the framework and support load. Also, this would need to be backed by an extensive test suite.

If you want to push this patch, I suggest that you try to start a thorough discussion on the trunk ML.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1860

    • Property Summary changed from Integration of the Dejavu ORM into the TurboGears to Integration of the Dejavu ORM in TurboGears
  • Ticket #1860 – Description

    initial v1  
    1 As you can imagine I have Alchemy, SQLObject and Dejavu; with the known import schema  
    2 Dejavu never quicks in... This approach have problems too, so any ideas will appreciated: 
     1As you can imagine I have Alchemy, SQLObject and Dejavu; with the known import schema Dejavu never quicks in... This approach has problems too, so any ideas will appreciated: 
    32 
    43{{{ 
     
    1817}}} 
    1918 
    20 Dejavu is configured via a dictionary or a config file. The problem is that multiple stores 
    21 could be involved and there is no URL schema here. 
    22 I have supported recursive dictionaries for configuring Dejavu; in the main dict each key 
    23 represents a store. The Class key of each store its the required Dejavu's storage Class. 
     19Dejavu is configured via a dictionary or a config file. The problem is that multiple stores could be involved and there is no URL schema here. I have supported recursive dictionaries for configuring Dejavu; in the main dict each key represents a store. The Class key of each store its the required Dejavu's storage Class. 
    2420 
    2521{{{ 
    2622# sqlobject.dburi="sqlite:///file_name_and_path" 
    27 dejagears.dburi={"mainstor":{"Class":"mysql","user":"mysql","passwd":"mysql","host":"localhost","db":"dejavu"}} 
     23dejagears.dburi = {"mainstor":{"Class":"mysql","user":"mysql","passwd":"mysql","host":"localhost","db":"dejavu"}} 
    2824dejagears.dburi = "dejavu.cfg" 
    2925dejagears.dburi = "/tmp/dejavu.cfg" 
    3026}}} 
    3127 
    32 Dicts are not hashable so I am using its id() as the key per uri (In the case of a dict uri)... 
     28Dicts are not hashable so I am using its `id()` as the key per dburi (in the case of a dict dburi)... 
    3329 
    3430{{{ 
     
    3834So dict like configuration and direct file configuration are supported but maybe that is too much overhead. 
    3935 
     36Right now the !SandBox is recovered from the !PackageHub using the getConnection() method... 
    4037 
    41 Right now the SandBox is recovered from the PackageHub using the getConnection() method... 
    42 That method returned the SQLObject connection and using Dejavu returns a SandBox, the real connection 
    43 could be found in the SandBox. 
     38This method returns the SQLObject connection and using Dejavu returns a !SandBox, the real connection can be found in the !SandBox. 
    4439 
    4540 
    46 The dejavusession.py is the CherryPy session storage filter; right now there is no package in 
    47 turbogears for this kind of filters... I don't know if sa and so filters are currently included. 
    48 It could be nice supporting this and providing three filters inside a TG package known as storage 
    49 o somenthing like that. The name dejavussesion.py is not even right (djstorage.py would be better). 
     41The ` dejavusession.py`  is the !CherryPy session storage filter; right now there is no package in turbogears for this kind of filters... I don't know if SA and SO filters are currently included. 
     42It could be nice to support this and to provide three filters inside a TG package known as "storage" or something like that. The name ` dejavussesion.py` is not even right (` djstorage.py`  would be better). 
    5043 
    51 This filter is inserted by hand in commands.py, so no support for fancy integration  
    52 here at the moment: 
     44This filter is inserted by hand in `commands.py`, so no support for fancy integration here at the moment: 
    5345 
    5446{{{ 
    55     from dejavusession import DejavuStorage 
    56     cherrypy.config.update( { "session_filter.storage_class" : DejavuStorage }) 
     47from dejavusession import DejavuStorage 
     48cherrypy.config.update({"session_filter.storage_class": DejavuStorage}) 
    5749}}} 
    5850 
    5951Check out the test application, it has been the same since 1.0.3.x version: 
     52 
    6053{{{svn checkout http://dejagears.googlecode.com/svn/branches/1.1.x/dejagears dejagears}}} 
    6154 
    6255This is the code posted at the trac: 
     56 
    6357{{{svn checkout http://dejagears.googlecode.com/svn/branches/1.1.x dejall}}} 
    6458 
     
    6660Tricky things... 
    6761After starting TG creates two Arenas... 
     62 
    6863{{{ 
    69642008-06-06 12:07:56,033 turbogears.database INFO Arena startup... 
     
    7368}}} 
    7469 
    75 And there should be only one Arena; this seems to be something that has to do 
    76 with two database.py imports from two threads... When auto-reloading is true, it only 
    77 restarts one Arena when reloading. And I am a bit lost here, to me It seems that  
    78 the auto reloaded thread Arena is in use. There must be a way to get the global Arena working... 
     70And there should be only one Arena; this seems to be something that has to do with two `database.py` imports from two threads... When auto-reloading is true, it only restarts one Arena when reloading. And I am a bit lost here, to me It seems that the auto reloaded thread Arena is in use. There must be a way to get the global Arena working... 
    7971 
    80