Quantcast

Dealing with datasources when adding a new AbstractPersistenceEventListener in plugins

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dealing with datasources when adding a new AbstractPersistenceEventListener in plugins

tomas lin
I'm playing around with the new AbstractPersistenceEventListener in Grails 2.0.

So far, it works pretty well.

It seems that the API expects a datasource to be passed to the
Listener, which is not quite reflected in the documentation. (
GRAILS-8528 )

It's not very clear to me how to handle the case where you have say, a
MongoDatasource and the typical hibernate Datasource in the same
application.

Should we:

1) allow Datasource to be set to null and override supportsSourceType
so that we just add the listener once to the entire application?

2) iterate through all the possible beans that match the datasource
pattern and add a new listener for each type of datasource?

The code of the AutoStampEventListener and DomainEventListener seem to
suggest that approach 2 is the way to go. (
https://github.com/SpringSource/grails-data-mapping/tree/master/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/events
).

However, the user guide section on custom event listeners suggest that
we shouldn't have to pass a datastore to the listener. (
http://grails.org/doc/latest/guide/GORM.html#eventsAutoTimestamping )

Any suggestions on best practices?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with datasources when adding a new AbstractPersistenceEventListener in plugins

Graeme Rocher-2
You make a valid point, we should probably take into account null or add a no args constructor. Feel free to raise an improvement request.

However, if you want to listen for events from MongoDB and Hibernate you'll need to create distinct listeners. Something like:

def beanMap = ctx.getBeansOfType(Datastore)
beanMap.values().each {
   def eventListener = new MyEventListener(it)
   ...
}

Cheers

-- 
Graeme Rocher

On Thursday, February 23, 2012 at 9:52 AM, Tomas Lin wrote:

I'm playing around with the new AbstractPersistenceEventListener in Grails 2.0.

So far, it works pretty well.

It seems that the API expects a datasource to be passed to the
Listener, which is not quite reflected in the documentation. (
GRAILS-8528 )

It's not very clear to me how to handle the case where you have say, a
MongoDatasource and the typical hibernate Datasource in the same
application.

Should we:

1) allow Datasource to be set to null and override supportsSourceType
so that we just add the listener once to the entire application?

2) iterate through all the possible beans that match the datasource
pattern and add a new listener for each type of datasource?

The code of the AutoStampEventListener and DomainEventListener seem to
suggest that approach 2 is the way to go. (
).

However, the user guide section on custom event listeners suggest that
we shouldn't have to pass a datastore to the listener. (

Any suggestions on best practices?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with datasources when adding a new AbstractPersistenceEventListener in plugins

tomas lin
Cool, raised a JIRA for this - http://jira.grails.org/browse/GRAILS-8824

Will look into submitting a patch to the documentation after work.

On Thu, Feb 23, 2012 at 1:08 PM, Graeme Rocher <[hidden email]> wrote:

> You make a valid point, we should probably take into account null or add a
> no args constructor. Feel free to raise an improvement request.
>
> However, if you want to listen for events from MongoDB and Hibernate you'll
> need to create distinct listeners. Something like:
>
> def beanMap = ctx.getBeansOfType(Datastore)
> beanMap.values().each {
>    def eventListener = new MyEventListener(it)
>    ...
> }
>
> Cheers
>
> --
> Graeme Rocher
>
> On Thursday, February 23, 2012 at 9:52 AM, Tomas Lin wrote:
>
> I'm playing around with the new AbstractPersistenceEventListener in Grails
> 2.0.
>
> So far, it works pretty well.
>
> It seems that the API expects a datasource to be passed to the
> Listener, which is not quite reflected in the documentation. (
> GRAILS-8528 )
>
> It's not very clear to me how to handle the case where you have say, a
> MongoDatasource and the typical hibernate Datasource in the same
> application.
>
> Should we:
>
> 1) allow Datasource to be set to null and override supportsSourceType
> so that we just add the listener once to the entire application?
>
> 2) iterate through all the possible beans that match the datasource
> pattern and add a new listener for each type of datasource?
>
> The code of the AutoStampEventListener and DomainEventListener seem to
> suggest that approach 2 is the way to go. (
> https://github.com/SpringSource/grails-data-mapping/tree/master/grails-datastore-gorm/src/main/groovy/org/grails/datastore/gorm/events
> ).
>
> However, the user guide section on custom event listeners suggest that
> we shouldn't have to pass a datastore to the listener. (
> http://grails.org/doc/latest/guide/GORM.html#eventsAutoTimestamping )
>
> Any suggestions on best practices?
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with datasources when adding a new AbstractPersistenceEventListener in plugins

Graeme Rocher-2
Great!

-- 
Graeme Rocher

On Thursday, February 23, 2012 at 2:50 PM, Tomas Lin wrote:

Cool, raised a JIRA for this - http://jira.grails.org/browse/GRAILS-8824

Will look into submitting a patch to the documentation after work.

On Thu, Feb 23, 2012 at 1:08 PM, Graeme Rocher <[hidden email]> wrote:
You make a valid point, we should probably take into account null or add a
no args constructor. Feel free to raise an improvement request.

However, if you want to listen for events from MongoDB and Hibernate you'll
need to create distinct listeners. Something like:

def beanMap = ctx.getBeansOfType(Datastore)
beanMap.values().each {
   def eventListener = new MyEventListener(it)
   ...
}

Cheers

--
Graeme Rocher

On Thursday, February 23, 2012 at 9:52 AM, Tomas Lin wrote:

I'm playing around with the new AbstractPersistenceEventListener in Grails
2.0.

So far, it works pretty well.

It seems that the API expects a datasource to be passed to the
Listener, which is not quite reflected in the documentation. (
GRAILS-8528 )

It's not very clear to me how to handle the case where you have say, a
MongoDatasource and the typical hibernate Datasource in the same
application.

Should we:

1) allow Datasource to be set to null and override supportsSourceType
so that we just add the listener once to the entire application?

2) iterate through all the possible beans that match the datasource
pattern and add a new listener for each type of datasource?

The code of the AutoStampEventListener and DomainEventListener seem to
suggest that approach 2 is the way to go. (
).

However, the user guide section on custom event listeners suggest that
we shouldn't have to pass a datastore to the listener. (

Any suggestions on best practices?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:


---------------------------------------------------------------------
To unsubscribe from this list, please visit:


Loading...