tg_admin needs to make appropriate calls into extensions' create_extension_model() function

[jtate]

In turbogears.identity.vistor's start_extension() the following exists:

    # Temporary until tg-admin can call create_extension_model
    create_extension_model()

Currently, the create_extension_model is called on startup slowing us down and wasting resources as a new object has to be created just for the duration of that call.

[jorge.vargas]

I'm not getting it right you mean that each time tg-admin is run the identity model is created?

also this is something that could be refractor on.  http://groups.google.com/group/turbogears-trunk/browse_thread/thread/766cf2021e2aab28

[jtate]

No, I mean that when tg-admin sql is run, it should run the create_extension_model(), in addition to creating the other models. Or at least that's what I assume that the comment is inferring.

[alberto]

Any patches for this? :)

[jtate]

Not really. I was filing it as a task so that it didn't get lost. I'll have to look into what it would take to add it to tg-admin sql.

[Chris Arndt]

See also #601, which says:

In order to fully support turbogears extensions, tg-admin should provide a 
command for creating the extension's data model (calling each extensions
create_extension_model method).

Currently Visit and Identity create their models during initialisation, 
which is causing some trouble for those who would like to more carefully 
control model creation.

Also, here's the relevant information from the mailing list thread referenced above:

Adam Jones wrote:

[..] in the Visit
system, [...] new plugins are registered by passing an initialized
object to 'turbogears.visit.enable_visit_plugin', and calling that
from a function appended to 'turbogears.startup.call_on_startup'. If
this were switched to an entry point (say, 'turbogears.visit.plugin')
it would be a simple matter of configuration to make this happen.

Alberto Valverde replied:

Now we have tg.util.load_class to load the  
identity/visit classses as defined by the configuration file. This  
could be changed to use pkg_resources.EntryPoint.parse which does  
something similar but in a more robust way and would open the door to  
define the classes in the configuration file using uris similar to  
paste deploy's.:

visit_class = egg:MyVisitPlugins#sa_visit
user_class = myapp.models:AppUser

That would load a visit_class from the MyVisitPlugins egg entry_point  
named "sa_visit" and a user class from myapp.models called AppUser.  
Both ways of loading the objects (ep from egg and explicit module  
path) would go through setuptools.

[chrisz]

Moved to  https://sourceforge.net/p/turbogears1/tickets/5/.