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

Ticket #1860 (closed enhancement: wontfix)

Opened 11 years ago

Last modified 10 years ago

Integration of the Dejavu ORM in TurboGears

Reported by: jrodrigo Owned by: anonymous
Priority: normal Milestone: 1.x
Component: TurboGears Version: 1.1 HEAD
Severity: normal Keywords: dejavu orm integration
Cc:

Description (last modified by Chris Arndt) (diff)

As 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:

# This key is non existant (turbogears.orm)
# there could exist import issues with this approach
# right now dejavu is the default for testing pourposes
_orm = turbogears.config.get( "turbogears.orm", "dejavu" )
if _orm == "sqlobject":
    sqlalchemy = None
    dejavu = None
elif _orm == "sqlalchemy":
    sqlobject = None
    dejavu = None
elif _orm == "dejavu":
    sqlobject = None
    sqlalchemy = None

Dejavu 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.

# sqlobject.dburi="sqlite:///file_name_and_path"
dejagears.dburi = {"mainstor":{"Class":"mysql","user":"mysql","passwd":"mysql","host":"localhost","db":"dejavu"}}
dejagears.dburi = "dejavu.cfg"
dejagears.dburi = "/tmp/dejavu.cfg"

Dicts are not hashable so I am using its id() as the key per dburi (in the case of a dict dburi)...

( self.uri, id( self.uri ) )[ isinstance( self.uri, dict ) ]

So dict like configuration and direct file configuration are supported but maybe that is too much overhead.

Right now the SandBox is recovered from the PackageHub using the getConnection() method...

This method returns the SQLObject connection and using Dejavu returns a SandBox, the real connection can be found in the SandBox.

The 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. It 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).

This filter is inserted by hand in commands.py, so no support for fancy integration here at the moment:

from dejavusession import DejavuStorage
cherrypy.config.update({"session_filter.storage_class": DejavuStorage})

Check out the test application, it has been the same since 1.0.3.x version:

svn checkout http://dejagears.googlecode.com/svn/branches/1.1.x/dejagears dejagears

This is the code posted at the trac:

svn checkout http://dejagears.googlecode.com/svn/branches/1.1.x dejall

Tricky things... After starting TG creates two Arenas...

2008-06-06 12:07:56,033 turbogears.database INFO Arena startup...
2008-06-06 12:07:56,069 turbogears.database INFO New store: mainstor
2008-06-06 12:07:59,159 turbogears.database INFO Arena startup...
2008-06-06 12:07:59,196 turbogears.database INFO New store: mainstor

And 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...

Attachments

database.py Download (23.3 KB) - added by jrodrigo 11 years ago.
Merged Dejavu into the current database subsystem
database.py.patch Download (7.6 KB) - added by jrodrigo 11 years ago.
A patch to insert the changes in database.py
dejavusession.py Download (2.7 KB) - added by jrodrigo 11 years ago.
A CherryPy? session storage filter based u
djprovider.py Download (17.5 KB) - added by jrodrigo 11 years ago.
Dejavu Identity Provider
djvisit.py Download (3.3 KB) - added by jrodrigo 11 years ago.
A Dejavu Identity Provider
entry_points.txt Download (1.6 KB) - added by jrodrigo 11 years ago.
Extended entry points file

Change History

Changed 11 years ago by jrodrigo

Merged Dejavu into the current database subsystem

Changed 11 years ago by jrodrigo

A patch to insert the changes in database.py

Changed 11 years ago by jrodrigo

A CherryPy? session storage filter based u

Changed 11 years ago by jrodrigo

Dejavu Identity Provider

Changed 11 years ago by jrodrigo

A Dejavu Identity Provider

Changed 11 years ago by jrodrigo

Extended entry points file

comment:1 Changed 11 years ago by Chris Arndt

  • Description modified (diff)
  • Summary changed from Integration of the Dejavu ORM into the TurboGears to Integration of the Dejavu ORM in TurboGears

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.

comment:2 Changed 11 years ago by faide

  • Milestone changed from 1.5 to 1.1

comment:3 Changed 11 years ago by Chris Arndt

  • Version changed from 1.1b1 to 1.1 HEAD

comment:4 Changed 10 years ago by faide

  • Milestone changed from 1.1 to __unclassified__

comment:5 Changed 10 years ago by jorge.vargas

  • Milestone changed from __unclassified__ to 1.x

comment:6 follow-up: ↓ 7 Changed 10 years ago by jrodrigo

An extract of my tg-admin...

$ tg-admin

Identity Providers

* sqlobject (TurboGears 1.0.4.4)
* sqlalchemy (TurboGears 1.0.4.4)
* dejavu (TurboGears 1.0.4.4)

Visit Managers

* sqlobject (TurboGears 1.0.4.4)
* sqlalchemy (TurboGears 1.0.4.4)
* dejavu (TurboGears 1.0.4.4)

This patch fully integrates the Dejavu ORM into the TurboGears web application server by cloning the SQLObject implementation. The benefit? TG will gain another ORM and a lot of new storage backends (Those provided by Dejavu).

That's all.

Maybe the current implementation of this patch is getting outdated. I will try to start a discussion on the trunk ML about this... If I get a bit of spare time.

comment:7 in reply to: ↑ 6 Changed 10 years ago by jorge.vargas

Replying to jrodrigo:

Maybe the current implementation of this patch is getting outdated. I will try to start a discussion on the trunk ML about this... If I get a bit of spare time.

Yes indeed that's the place to go to lobby for your feature to get added, thanks for keeping up

comment:8 Changed 10 years ago by Chris Arndt

  • Status changed from new to closed
  • Resolution set to wontfix

Since there has been no further feedback on this for several months, I'm closing this ticket as "wontfix".

Note: See TracTickets for help on using tickets.