Plugin globals, and sharing database connections between plugins
Hi guys, There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's. One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module. For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that: https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247... I'd like to ask for comments from the floor ;-) As an example, I have successfully used the above to create a DBIC provider for Plugins::Auth::Extensible, which uses a database connection handle from Plugins::DBIC Andy
On Tue, 17 Feb 2015, Andrew Beverley wrote:
There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's.
It works in D1, not in D2.
One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module.
For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that:
https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247...
I'd like to ask for comments from the floor ;-)
This does not work for me. I do not want a global bdi. I compose sites using partial apps using unrelated shemas. Yes, I have a DPAE provider using DBIC. But other partial-apps do not know this, use there own shema. "global data" sounds like config.yml I would like a Dancer::Unified::Config used by D1 and D2, to keep it DRY. -- Henk TODO: Dancer::Plugin should export "on_plugin_import". Dancer2::Plugin should export "add_hook".
On Wed, 2015-02-18 at 07:26 +0100, Henk van Oers wrote:
On Tue, 17 Feb 2015, Andrew Beverley wrote:
There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's.
It works in D1, not in D2.
Okay, I've probably muddied the waters here. I'm trying to think of this from the point of view of the end result. For me, that's reusing a database connection in different plugins. I don't actually need to use one plugin inside another (although it might be useful for other scenarios).
One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module.
For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that:
https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247...
I'd like to ask for comments from the floor ;-)
This does not work for me. I do not want a global bdi.
The advantage of this is that you can reuse the same database connection handle. From what I can tell, reusing one plugin inside another would still open another database connection. Not a major issue, but it seems cleaner to use an existing one.
I compose sites using partial apps using unrelated shemas. Yes, I have a DPAE provider using DBIC. But other partial-apps do not know this, use there own shema.
"global data" sounds like config.yml I would like a Dancer::Unified::Config used by D1 and D2, to keep it DRY.
Sorry if I've misunderstood, but do you mean that you want to share configuration options between different apps?
On Wed, Feb 18, 2015 at 2:35 AM, Andrew Beverley <andy@andybev.com> wrote:
On Wed, 2015-02-18 at 07:26 +0100, Henk van Oers wrote:
On Tue, 17 Feb 2015, Andrew Beverley wrote:
There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's.
It works in D1, not in D2.
Okay, I've probably muddied the waters here. I'm trying to think of this from the point of view of the end result. For me, that's reusing a database connection in different plugins. I don't actually need to use one plugin inside another (although it might be useful for other scenarios).
One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module.
For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that:
https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247...
I'd like to ask for comments from the floor ;-)
This does not work for me. I do not want a global bdi.
The advantage of this is that you can reuse the same database connection handle. From what I can tell, reusing one plugin inside another would still open another database connection. Not a major issue, but it seems cleaner to use an existing one.
In the case of the DBIC plugin, its schema keyword is essentially memoized (schema objects are cached in memory), so it would not open another database connection. Unless of course if schema() was called with a different argument. -Naveed
I compose sites using partial apps using unrelated shemas. Yes, I have a DPAE provider using DBIC. But other partial-apps do not know this, use there own shema.
"global data" sounds like config.yml I would like a Dancer::Unified::Config used by D1 and D2, to keep it DRY.
Sorry if I've misunderstood, but do you mean that you want to share configuration options between different apps?
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Wed, 2015-02-18 at 03:18 -0500, Naveed Massjouni wrote:
The advantage of this is that you can reuse the same database connection handle. From what I can tell, reusing one plugin inside another would still open another database connection. Not a major issue, but it seems cleaner to use an existing one.
In the case of the DBIC plugin, its schema keyword is essentially memoized (schema objects are cached in memory), so it would not open another database connection. Unless of course if schema() was called with a different argument.
It's only memoized within each instantiation of the object. So if you "use Dancer2::Plugin::DBIC" within another plugin, you get a second connection. Correct? Andy
On Wed, Feb 18, 2015 at 4:09 AM, Andrew Beverley <andy@andybev.com> wrote:
On Wed, 2015-02-18 at 03:18 -0500, Naveed Massjouni wrote:
The advantage of this is that you can reuse the same database connection handle. From what I can tell, reusing one plugin inside another would still open another database connection. Not a major issue, but it seems cleaner to use an existing one.
In the case of the DBIC plugin, its schema keyword is essentially memoized (schema objects are cached in memory), so it would not open another database connection. Unless of course if schema() was called with a different argument.
It's only memoized within each instantiation of the object. So if you "use Dancer2::Plugin::DBIC" within another plugin, you get a second connection. Correct?
Andy
I don't think that is correct. The schema objects are cached in a $schemas hashref that is lexically scoped to the Dancer2::Plugin::DBIC package. https://github.com/ironcamel/Dancer2-Plugin-DBIC/blob/master/lib/Dancer2/Plu... There can only be one instance of this "cache" (the $schemas hashref) per process. -Naveed
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Wed, 2015-02-18 at 04:21 -0500, Naveed Massjouni wrote:
On Wed, Feb 18, 2015 at 4:09 AM, Andrew Beverley <andy@andybev.com> wrote:
On Wed, 2015-02-18 at 03:18 -0500, Naveed Massjouni wrote:
The advantage of this is that you can reuse the same database connection handle. From what I can tell, reusing one plugin inside another would still open another database connection. Not a major issue, but it seems cleaner to use an existing one.
In the case of the DBIC plugin, its schema keyword is essentially memoized (schema objects are cached in memory), so it would not open another database connection. Unless of course if schema() was called with a different argument.
It's only memoized within each instantiation of the object. So if you "use Dancer2::Plugin::DBIC" within another plugin, you get a second connection. Correct?
Andy
I don't think that is correct. The schema objects are cached in a $schemas hashref that is lexically scoped to the Dancer2::Plugin::DBIC package. https://github.com/ironcamel/Dancer2-Plugin-DBIC/blob/master/lib/Dancer2/Plu... There can only be one instance of this "cache" (the $schemas hashref) per process.
Okay, I'll need to look at it a bit more closely then. When I did some initial testing with reusing the DBIC plugin within DPAE, the $schemas hashref was undefined when called from DPAE, despite having being defined in the main Dancer App. But I could have been doing something wrong. Thanks, Andy
On Wed, 2015-02-18 at 04:21 -0500, Naveed Massjouni wrote:
On Wed, Feb 18, 2015 at 4:09 AM, Andrew Beverley <andy@andybev.com> wrote:
On Wed, 2015-02-18 at 03:18 -0500, Naveed Massjouni wrote:
The advantage of this is that you can reuse the same database connection handle. From what I can tell, reusing one plugin inside another would still open another database connection. Not a major issue, but it seems cleaner to use an existing one.
In the case of the DBIC plugin, its schema keyword is essentially memoized (schema objects are cached in memory), so it would not open another database connection. Unless of course if schema() was called with a different argument.
It's only memoized within each instantiation of the object. So if you "use Dancer2::Plugin::DBIC" within another plugin, you get a second connection. Correct?
Andy
I don't think that is correct. The schema objects are cached in a $schemas hashref that is lexically scoped to the Dancer2::Plugin::DBIC package. https://github.com/ironcamel/Dancer2-Plugin-DBIC/blob/master/lib/Dancer2/Plu... There can only be one instance of this "cache" (the $schemas hashref) per process.
Thanks for the feedback Naveed. It prompted me to take another look at what I was trying to do with the DPAE DBIC plugin, and I think I've found another way of doing it. I'll post a PR shortly. Thanks, Andy
On Wed, 18 Feb 2015, Andrew Beverley wrote:
On Wed, 2015-02-18 at 07:26 +0100, Henk van Oers wrote:
On Tue, 17 Feb 2015, Andrew Beverley wrote:
There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's.
It works in D1, not in D2.
Okay, I've probably muddied the waters here. I'm trying to think of this from the point of view of the end result. For me, that's reusing a database connection in different plugins.
A database connection should be reused, not only in a plugin.
I don't actually need to use one plugin inside another (although it might be useful for other scenarios).
Mmm. I do need this. (Or make exporters to make the keywords)
One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module.
For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that:
https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247...
I'd like to ask for comments from the floor ;-)
This does not work for me. I do not want a global bdi.
The advantage of this is that you can reuse the same database connection handle.
There is no "the same database connection". I reuse all connections.
From what I can tell, reusing one plugin inside another would still open another database connection.
Not in D1.
Not a major issue, but it seems cleaner to use an existing one.
You can do that in D2 to. But it looks more verbose...
I compose sites using partial apps using unrelated shemas. Yes, I have a DPAE provider using DBIC. But other partial-apps do not know this, use there own shema.
"global data" sounds like config.yml I would like a Dancer::Unified::Config used by D1 and D2, to keep it DRY.
Sorry if I've misunderstood, but do you mean that you want to share configuration options between different apps?
Yes. And not only between Dancer versions, but whatever framework. -- Henk
My gut feeling is that as an application developer I could make some use of it but as a plugin developer I would much prefer to use function/method calls and I would much prefer to expose only function calls and not guarantee the nature of any global variables. One reason is order of execution. What happens if the global is not (and cannot be) set until a given keyword is called the first time? Daniel On 17 February 2015 at 12:56, Andrew Beverley <andy@andybev.com> wrote:
Hi guys,
There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's.
One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module.
For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that:
https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247...
I'd like to ask for comments from the floor ;-)
As an example, I have successfully used the above to create a DBIC provider for Plugins::Auth::Extensible, which uses a database connection handle from Plugins::DBIC
Andy
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Wed, 2015-02-18 at 08:32 +0000, D Perrett wrote:
My gut feeling is that as an application developer I could make some use of it but as a plugin developer I would much prefer to use function/method calls and I would much prefer to expose only function calls and not guarantee the nature of any global variables.
One reason is order of execution. What happens if the global is not (and cannot be) set until a given keyword is called the first time?
Thanks for the feedback Daniel. All makes a lot of sense when you put it like that. I think I've got another way of doing what I was trying to achieve, so I'll try and finish that and then I'll post some details shortly. Thanks, Andy
On Tue, 2015-02-17 at 12:56 +0000, Andrew Beverley wrote:
Hi guys,
There has been discussion over the last few weeks about the plugin architecture having problems, in terms of using one plugin's functions inside another's.
One area that this is particularly problematic is using a database plugin in another plugin, for example in an authentication module.
For the latter scenario (but probably not the former), I thought it might be useful if a plugin could register global data, that could be accessed by other plugins. This patch does exactly that:
https://github.com/ctrlo/Dancer2/commit/9383ade1e46691106e835cd9155976fa5247...
This is what I did in the end: https://github.com/racke/Dancer2-Plugin-Auth-Extensible/pull/7 As always, any comments welcome. Andy
participants (5)
-
Andrew Beverley -
D Perrett -
Henk van Oers -
Naveed Massjouni -
Naveed Massjouni