On Wed, Jul 4, 2018 at 11:46 AM Emmanuel Bernard
wrote:
> Having the create-warn by default and allowing the user to move to
> create or fail is a good compromise. Vlad, in the documentation, we can
> have a get ready for production section that mention this problem and
> many others :)
>
OK,
Let's keep this consistent and use the create-warn for all cases.
I understand why the user raised the original JIRA, and yes on paper,
failing is the safer prod friendly option.
But we must cater to the ease of development too. The development
workflow and experience is an important aspect that
Hi,
Current status:
- short names and compatibility layer on the ORM side: merged
- Radim will get the Infinispan region factory up to speed (Thanks!)
- we merged the configuration knobs to allow the automatic creation of
caches:
. default for Ehcache: create-warn: cache will be automatically
I think they are afraid of you Steve :D
When asking, we could make it clear where we stand:
- I feel unsure and need someone else to back me up, ideally the project
lead
- I think I'm right but let's see if Steve or other knowledgable person
comes with a strong argument against
- I don't want
On Tue, Jul 3, 2018 at 5:11 AM Yoann Rodiere wrote:
> 2) This is easily handled by the providers, if they wish. They would
>> simply map any undefined regions/caches to a pre-defined one (probably
>> after warning the user). Keep in mind that region != cache. A provider
>> might map multiple
>
> 2) This is easily handled by the providers, if they wish. They would
> simply map any undefined regions/caches to a pre-defined one (probably
> after warning the user). Keep in mind that region != cache. A provider
> might map multiple region names to a single cache. That was always the
>
Then not sure why you ask if you already plan on your answer ;)
On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet
wrote:
> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole wrote:
>
>> 1) That was specifically requested
>>
>
> Sure. And we also have users who are unhappy with the new setup.
>
> This
On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole wrote:
> 1) That was specifically requested
>
Sure. And we also have users who are unhappy with the new setup.
This was also changed for the legacy Ehcache 2 provider which is a pity
IMHO.
> 2) This is easily handled by the providers, if they
Yes, what you describe is exactly the hybrid approach I suggested.
On Mon, Jul 2, 2018 at 3:52 PM Vlad Mihalcea
wrote:
> The short name approach sounds goid and would accommodate any future cache
> region implementation changes.
>
> For 5.3, I'd say we allow the old named to be resolved to the
The short name approach sounds goid and would accommodate any future cache
region implementation changes.
For 5.3, I'd say we allow the old named to be resolved to the new ones,
like symbolic links.
This will allow users to migrate to 5.3 without changing existing
ehcache.xml configs.
We could
1) That was specifically requested
2) This is easily handled by the providers, if they wish. They would
simply map any undefined regions/caches to a pre-defined one (probably
after warning the user). Keep in mind that region != cache. A provider
might map multiple region names to a single
Hi Steve,
Glad to have you back! Hope yo got some rest.
On Mon, Jul 2, 2018 at 5:28 PM Steve Ebersole wrote:
> Overall what I would suggest is a hybrid approach where we move to a
> "short name" solution much like we have for most other config values. So,
> e.g., the name of the default query
Changing the name of the default query results cache I can see being a
problem in retrospect. That is something the user might want to
configure.
I am much less convinced about the update-timestamps cache. I guess it
would depend on what they are configuring.
Overall what I would suggest is a
Hi all,
So following our off-list discussions , I wanted to share a document we
wrote with Yoann with some details about the usability/compatibility of the
new cache implementation in 5.3:
https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing
(The
14 matches
Mail list logo
