Hi,
I've had a very interesting discussion on Twitter regarding MarisDB:
https://twitter.com/bobbytank42/status/828529312731013121
And, since MySQL and MariaDB have gone in different directions, we might
want to provide MariaDB Dialects as well.
For instance, it's not very intuitive for a Hiber
+1 to split them. I don't expect people to consider them "the same" anymore..
We probably should have split them even if there had been no technical
differences, just to make it clear which one needs to be configured.
On 6 February 2017 at 12:37, Vlad Mihalcea wrote:
> Hi,
>
> I've had a very in
Fwiw Dialect discovery is far and away the preferred solution for
"specifying" Dialect. That said, I am ok with splitting off Dialect(s)
specific to MariaDB.
Relatedly, I wonder if we should begin to remove the Dialects we have
marked as deprecated and whether we should consider a "legacy" repo
+1 to fail fast with the explicit error in that case.
> On 1 Feb 2017, at 11:33, Gunnar Morling wrote:
>
> Hi,
>
> JPA defines for validation mode "auto" that bean validation must occur
> if a BV provider is present and that no validation shall occur
> otherwise.
>
> What should happen though
I'll create a new Jira issue for the MariaDB Dialects.
For the deprecated Dialects, I'd just remove them. But the Javassist
support can be moved to a to a hibernate-legacy GitHub repository.
Vlad
On Mon, Feb 6, 2017 at 3:19 PM, Steve Ebersole wrote:
> Fwiw Dialect discovery is far and away the
+1 for both
On 02/06/2017 08:19 AM, Steve Ebersole wrote:
> Fwiw Dialect discovery is far and away the preferred solution for
> "specifying" Dialect. That said, I am ok with splitting off Dialect(s)
> specific to MariaDB.
>
> Relatedly, I wonder if we should begin to remove the Dialects we have
>
+1 for MariaDB dialect.
+1 also for the deprecated repos
On 6 February 2017 at 15:05, Vlad Mihalcea wrote:
> I'll create a new Jira issue for the MariaDB Dialects.
>
> For the deprecated Dialects, I'd just remove them. But the Javassist
> support can be moved to a to a hibernate-legacy GitHub
Hey all,
On the license, I think ASL 2.0 is the best for such project.
On the group id, am I right that this project is some utilities used by us
internally? And would not be imported by a user?
If true then I’d avoid common as it feels like something that a user would
import. internal could wo
Ditto -- a cleanup would be fantastic.
On 02/06/2017 10:20 AM, andrea boriero wrote:
> +1 for MariaDB dialect.
>
> +1 also for the deprecated repos
>
>
> On 6 February 2017 at 15:05, Vlad Mihalcea wrote:
>
>> I'll create a new Jira issue for the MariaDB Dialects.
>>
>> For the deprecated Dialects
On 6 February 2017 at 15:21, Emmanuel Bernard wrote:
> Hey all,
>
> On the license, I think ASL 2.0 is the best for such project.
> On the group id, am I right that this project is some utilities used by us
> internally? And would not be imported by a user?
That's what I hope should be the inten
Your prototype is very Hibernate Search tainted. I wonder how or whether we
want it reusable across Hibernate Validator, Search and possibly more.
Have you captured somewhere the discussion about the new document builder so I
could get a better grip of what’s at bay?
Would this reverse of logic
On 6 February 2017 at 13:19, Steve Ebersole wrote:
> Fwiw Dialect discovery is far and away the preferred solution for
> "specifying" Dialect. That said, I am ok with splitting off Dialect(s)
> specific to MariaDB.
Right I agree auto-detection is preferred. Are you suggesting that we
actually ca
12 matches
Mail list logo
