7.0.0 - Need mechanism to expose correct autoTimestampEventListener
- Dominant language
- Groovy
- Stars
- 2.9k
- Forks
- 975
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 92
Description
When an application has multiple datasources or connections, things become problematic with autoTimestampEventListener because it is difficult to access the correct one. For each datastore or connection, a new autoTimestampEventListener is registered.
The [documentation](https://gorm.grails.org/latest/hibernate/manual/index.html#eventsAutoTimestamping) states:
> . If you already have access to the datastore, you can execute the getAutoTimestampEventListener method. If you don’t have access to the datastore, inject the autoTimestampEventListener bean.
You can't just inject the autoTimestampEventListener bean because there are multiple registered and having access to the datastore doesn't help if there are multiple connections (For instance a gorm mongo db with 2 connections will result in 2 autoTimestampEventListeners.
For instance, the following will not work if `Car` and `Person` are in separate data sources or connections.
```groovy
def car = new Car(name: 'Herbie')
def person = new Person(name: 'Bob')
autoTimestampEventListener.withoutTimestamps {
car.save(flush: true)
person.save(flush: true)
}
```
It would be nice if there was a mechanism to expose the correct `autoTimestampEventListener` for a given domain class.
Perhaps even being able to do the following:
```groovy
def car = new Car(name: 'Herbie')
def person = new Person(name: 'Bob')
Car.autoTimestampEventListener.withoutTimestamps {
car.save(flush: true)
}
Person.autoTimestampEventListener.withoutTimestamps {
person.save(flush: true)
}
```
Contributor guide
Research direction
Start with the autoTimestampEventListener documentation and the getAutoTimestampEventListener entry point described in the issue. Reproduce the multi-datasource or multi-connection example, then define and verify a mechanism that selects the correct listener for each domain class and connection.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- groovy
- Domain
- backend, database
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100