Deprecate JdbcMessageStore#pollMessageFromGroup in favor of JdbcChannelMessageStore [INT-3225]

[spring-operator]

Artem Bilan opened INT-3225 and commented

... And make it as UnsupportedOperationException in the next major release and change the JDBC shema to two tables, as to have three ones will be overhead without queue ability. It maybe a task of existing JdbcMessageStore refactoring tickets

---

Issue Links:

• Refactor JdbcMessageStore - Provide separate implementations for MessageStore and MessageGroupStore [INT-2672] #6647 Refactor JdbcMessageStore - Provide separate implementations for MessageStore and MessageGroupStore

[spring-operator]

Artem Bilan commented

Gary Russell, there is some crazy thought. How about to combine both existing JDBC MS implementation to one class and determine which one to invoke dependently of context of call.
In this case users will be able just configure <int-jdbc:message-store> with approriate properties (e.g. query-provider) and use it everywhere - in aggregators, claim-ckeck and channels.
With those there is no need to deprecate pollMessageFromGroup method, but we should invent an option how to determine a delegate MS implementation for case addMessageToGroup and others.
WDYT?

[spring-operator]

Gary Russell commented

That sounds like a reasonable plan (as long as it doesn't make the DDL too confusing).

However, it should move to 4.0; we are a week or so away from GA and I'd rather us spend time on clean up/docs; also, this would be a big change between RC and GA.

[spring-operator]

Artem Bilan commented

No-no. Of course I understand what it means.
Just want to consult: to deprecate it now or leave as is, if we will decide to squash solutions as I suggested.
Then this issue doesn't make sense and should be 'Won't fix'

[spring-operator]

Gary Russell commented

Yes; leave as-is.

[spring-operator]

Artem Bilan commented

Will be revised in the next release in favor of to use both implementations as strtegies in the one class.

[spring-operator]

Gary Russell commented

FYI, always close, rather than resolve "won't fix" JIRAs, otherwise they'll stick in 'resolved' status (we generally move resolved to closed when we release).