[hibernate-dev] MariaDB-specific Dialects

[Vlad Mihalcea]

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 Hibernate user to figure out
that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
microsecond precision which have been available since MariaDB 5.3:

https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/

Let me know what you think.

Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[Sanne Grinovero]

+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 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 Hibernate user to figure out
> that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
> microsecond precision which have been available since MariaDB 5.3:
>
> https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
>
> Let me know what you think.
>
> Vlad
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[Steve Ebersole]

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 where
we can dump these (as well as other removed features - Javassist support
e.g.).  The expectation would be no continued development, but would make
them  more readily available to users who still needed them as opposed to
simply dropping them completely.  We could even alter the license of those
classes to be less restrictive than LGPL in terms of contributing back
changes.

On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero  wrote:

> +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 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 Hibernate user to figure out
> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
> > microsecond precision which have been available since MariaDB 5.3:
> >
> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
> >
> > Let me know what you think.
> >
> > Vlad
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap

[Emmanuel Bernard]

+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 if a BV provider such as HV is present but
> it fails to bootstrap? In case of HV this happens if no expression
> language implementation can be found.
> 
> Currently, the user has a very hard time to find out about this, as
> this exception essentially is suppressed (for mode "callback" the
> exception is raised).
> 
> Should we raise a specific exception in HV if it cannot be
> bootstrapped? In ORM, we could handle that one specifically and raise
> it also if for validation mode "auto" (would have to happen
> reflectively, though, as to avoid a hard dependency).
> 
> I can do this change but first wanted to make sure that this is inline
> with what you all think should be done.
> 
> Thanks,
> 
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[Vlad Mihalcea]

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 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 where
> we can dump these (as well as other removed features - Javassist support
> e.g.).  The expectation would be no continued development, but would make
> them  more readily available to users who still needed them as opposed to
> simply dropping them completely.  We could even alter the license of those
> classes to be less restrictive than LGPL in terms of contributing back
> changes.
>
> On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero  wrote:
>
>> +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 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 Hibernate user to figure out
>> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
>> > microsecond precision which have been available since MariaDB 5.3:
>> >
>> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
>> >
>> > Let me know what you think.
>> >
>> > Vlad
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[Chris Cranford]

+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
> marked as deprecated and whether we should consider a  "legacy" repo where
> we can dump these (as well as other removed features - Javassist support
> e.g.).  The expectation would be no continued development, but would make
> them  more readily available to users who still needed them as opposed to
> simply dropping them completely.  We could even alter the license of those
> classes to be less restrictive than LGPL in terms of contributing back
> changes.
>
> On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero  wrote:
>
>> +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 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 Hibernate user to figure out
>>> that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
>>> microsecond precision which have been available since MariaDB 5.3:
>>>
>>> https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
>>>
>>> Let me know what you think.
>>>
>>> Vlad
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[andrea boriero]

+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 repository.
>
> Vlad
>
> On Mon, Feb 6, 2017 at 3:19 PM, 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
> > marked as deprecated and whether we should consider a  "legacy" repo
> where
> > we can dump these (as well as other removed features - Javassist support
> > e.g.).  The expectation would be no continued development, but would make
> > them  more readily available to users who still needed them as opposed to
> > simply dropping them completely.  We could even alter the license of
> those
> > classes to be less restrictive than LGPL in terms of contributing back
> > changes.
> >
> > On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero 
> wrote:
> >
> >> +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 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 Hibernate user to figure
> out
> >> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps
> with
> >> > microsecond precision which have been available since MariaDB 5.3:
> >> >
> >> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
> >> >
> >> > Let me know what you think.
> >> >
> >> > Vlad
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Commons project

[Emmanuel Bernard]

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 work. Some other proposal (to be combined or not):
- utilities
- infra
- toolbox

On the theme, I don't have a definitive opinion but I think like Guillaume I’d 
prefer a lighter customized version of the default Asciidoc theme rather than 
the heavyweight one.

Emmanuel

> On 31 Jan 2017, at 12:27, Guillaume Smet  wrote:
> 
> On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling 
> wrote:
> 
>> == Repo organization ==
>> 
>> I would prefer to have the AsciiDoc style, shared testing utilities
>> and other utilities in separate repos, not a shared one. To me, a repo
>> represents a coherent unit of "things" with its own lifecycle. Updates
>> to the style should not mandate an update of the version of the
>> testing and other utilities, so they should be in their own repo. This
>> should also make it easier in terms of licenses (no need for
>> relicensing).
>> 
> 
> Yeah, that was my first intention but I got outnumbered and to be honest I
> don't really care as long as they are purely internal projects. I'll let
> Yoann and Sanne explain their point of view as they will do that better
> than me (IIRC, it was mostly about the maintenance cost but I'm not sure it
> makes a difference if the lifecycles are completely different).
> 
> Anyway, it does not solve the license issue. As per our discussion last
> week, if we have some general utilities to share between the NoORM projects
> for instance, we would probably like to copy the sources of the utilities
> to avoid conflicting dependencies when depending on 2 of the projects
> (probably using
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-dependencies-sources.html).
> In this case, I think we would need to dual license (ASL 2 + LGPL) the
> utilities as the sources will be distributed with the rest of the projects.
> 
> So, if I try to sum it up:
> 
> == GroupId ==
> 
> 2 proposals:
> - org.hibernate.common (the same as hibernate-commons-annotations)
> - org.hibernate.internal
> 
> (let's drop my initial org.hibernate.commons proposal, it's too confusing
> with org.hibernate.common)
> 
> == The license ==
> 
> The license: probably better to dual license everything under the ASL2 and
> the LGPL - especially if we start to share utilities.
> 
> Will check with Emmanuel when he's back.
> 
> == The AsciiDoctor theme ==
> 
> We mostly agree that it's probably better to converge on a similar layout.
> 
> Steve seems to be strongly attached to the Hibernate theme.
> 
> I personally don't like it and think it would be more painful to maintain
> in the long term as it overrides more things. Sanne was also more convinced
> by the white banner.
> 
> If I sum up the differences between the 2 themes (
> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html
> vs http://docs.jboss.org/hibernate/beta/html_single/):
> - black banner vs white banner
> - original Docbook icons vs font based icons (Font Awesome)
> - dark blue titles vs standard red ones
> - admonitions are totally different (compare
> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#naming
> and the end of this paragraph
> http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-threadsandconnections
> )
> - a lots of fonts loaded in the ORM doc but I must admit that I think most
> are useless:
> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-fonts.css
> so we could probably clean this up
> - more overrides (compare
> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-layout.css
> vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so
> more maintenance if the HTML output of AsciiDoctor is changed - note that
> I'm new to AsciiDoctor so I don't know how stable the HTML output is
> 
> The ORM output might have been better than the default AsciiDoctor output
> at the time it was made, but as of now I really think the current
> AsciiDoctor output is more pleasant to read and more modern. And we would
> benefit from future improvements for free.
> 
> -- 
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[Brett Meyer]

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, 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 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
>> where
>>> we can dump these (as well as other removed features - Javassist support
>>> e.g.).  The expectation would be no continued development, but would make
>>> them  more readily available to users who still needed them as opposed to
>>> simply dropping them completely.  We could even alter the license of
>> those
>>> classes to be less restrictive than LGPL in terms of contributing back
>>> changes.
>>>
>>> On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero 
>> wrote:
 +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 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 Hibernate user to figure
>> out
> that they need to use the MySQLInnoDb57Dialect to handle Timestamps
>> with
> microsecond precision which have been available since MariaDB 5.3:
>
> https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
>
> Let me know what you think.
>
> Vlad
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Commons project

[Sanne Grinovero]

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 intent as well. This repo would be
useful to e.g. not rebuild the same checkstyle extensions over and
over, but I'd not like to share actual runtime code from this project.
Project inter-dependency matrix is complex enough for end-users.

Thanks,
Sanne

>
> If true then I’d avoid common as it feels like something that a user would 
> import. internal could work. Some other proposal (to be combined or not):
> - utilities
> - infra
> - toolbox
>
> On the theme, I don't have a definitive opinion but I think like Guillaume 
> I’d prefer a lighter customized version of the default Asciidoc theme rather 
> than the heavyweight one.
>
> Emmanuel
>
>> On 31 Jan 2017, at 12:27, Guillaume Smet  wrote:
>>
>> On Tue, Jan 31, 2017 at 11:34 AM, Gunnar Morling 
>> wrote:
>>
>>> == Repo organization ==
>>>
>>> I would prefer to have the AsciiDoc style, shared testing utilities
>>> and other utilities in separate repos, not a shared one. To me, a repo
>>> represents a coherent unit of "things" with its own lifecycle. Updates
>>> to the style should not mandate an update of the version of the
>>> testing and other utilities, so they should be in their own repo. This
>>> should also make it easier in terms of licenses (no need for
>>> relicensing).
>>>
>>
>> Yeah, that was my first intention but I got outnumbered and to be honest I
>> don't really care as long as they are purely internal projects. I'll let
>> Yoann and Sanne explain their point of view as they will do that better
>> than me (IIRC, it was mostly about the maintenance cost but I'm not sure it
>> makes a difference if the lifecycles are completely different).
>>
>> Anyway, it does not solve the license issue. As per our discussion last
>> week, if we have some general utilities to share between the NoORM projects
>> for instance, we would probably like to copy the sources of the utilities
>> to avoid conflicting dependencies when depending on 2 of the projects
>> (probably using
>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/using-dependencies-sources.html).
>> In this case, I think we would need to dual license (ASL 2 + LGPL) the
>> utilities as the sources will be distributed with the rest of the projects.
>>
>> So, if I try to sum it up:
>>
>> == GroupId ==
>>
>> 2 proposals:
>> - org.hibernate.common (the same as hibernate-commons-annotations)
>> - org.hibernate.internal
>>
>> (let's drop my initial org.hibernate.commons proposal, it's too confusing
>> with org.hibernate.common)
>>
>> == The license ==
>>
>> The license: probably better to dual license everything under the ASL2 and
>> the LGPL - especially if we start to share utilities.
>>
>> Will check with Emmanuel when he's back.
>>
>> == The AsciiDoctor theme ==
>>
>> We mostly agree that it's probably better to converge on a similar layout.
>>
>> Steve seems to be strongly attached to the Hibernate theme.
>>
>> I personally don't like it and think it would be more painful to maintain
>> in the long term as it overrides more things. Sanne was also more convinced
>> by the white banner.
>>
>> If I sum up the differences between the 2 themes (
>> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html
>> vs http://docs.jboss.org/hibernate/beta/html_single/):
>> - black banner vs white banner
>> - original Docbook icons vs font based icons (Font Awesome)
>> - dark blue titles vs standard red ones
>> - admonitions are totally different (compare
>> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#naming
>> and the end of this paragraph
>> http://docs.jboss.org/hibernate/beta/html_single/#search-batchindexing-threadsandconnections
>> )
>> - a lots of fonts loaded in the ORM doc but I must admit that I think most
>> are useless:
>> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-fonts.css
>> so we could probably clean this up
>> - more overrides (compare
>> http://docs.jboss.org/hibernate/stable/orm/userguide/html_single/css/hibernate-layout.css
>> vs http://docs.jboss.org/hibernate/beta/html_single/css/hibernate.css) so
>> more maintenance if the HTML output of AsciiDoctor is changed - note that
>> I'm new to AsciiDoctor so I don't know how stable the HTML output is
>>
>> The ORM output might have been better than the default AsciiDoctor output
>> at the time it was made, but as of now I really think the current
>> AsciiDoctor output is more pleasant to read and more modern. And we would
>> benefit from future improvements for free.
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org

Re: [hibernate-dev] [HV/HSEARCH] Free form

[Emmanuel Bernard]

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 also be embraced by Hibernate Validator? There are 
runtime decisions done in HV during traversal that made me doubt that it would 
be as pertinent.



> On 30 Jan 2017, at 11:21, Yoann Rodiere  wrote:
> 
> Hi,
> 
> Did the same this week-end, and adapted your work to match the bigger picture 
> of what we discussed on Friday.
> Basically the "StructureTraverser" is now called "ValueProcessor", because 
> it's not responsible for exposing the internals of a structure anymore, but 
> only to process a structure according to previously defined metadata, passing 
> the output to the "DocumentContext". I think it's the second option you 
> suggested. It makes sense in my opinion, since metadata will be defined 
> differently for different source types (POJO, JSON, ...).
> This design allows in particular what Sanne suggested: when bootstrapping, we 
> can build some kind of "walker" (a composition of "ValueProcessors") from the 
> metadata, and avoid metadata lookup at runtime.
> 
> The snippet is there: 
> https://gist.github.com/yrodiere/9ff8fe8a8c7f59c1a051b36db20fbd4d 
> 
> 
> I'm sure it'll have to be refined to address additional constraints, but in 
> its current state it seems to address all of our requirements.
> 
> Yoann Rodière mailto:yrodi...@redhat.com>>
> Software Engineer
> Red Hat / Hibernate NoORM Team
> 
> On 27 January 2017 at 18:23, Emmanuel Bernard  > wrote:
> I took the flight home to play with free form and specifically how we would 
> retrieve data from the free form structure.
> By free-form I mean non POJO but they will have schema (not expressed here).
> 
> https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b9934063792a050f537
>  
> 
> 
> And in particular
> https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/StructureTraverser.java
>  
> 
> https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/pojo/impl/PojoStructureTraverser.java
>  
> 
> 
> It probably does not compile, I could not make the build work.
> 
> I figured it was important to dump this raw thinking because it will 
> influence and will be influenced by the redesign of the DocumentBuilder of 
> Hibernate Search.
> 
> There are several options for traversing a free form structure
> - expose  the traversing API as a holder to  navigate all properties per 
> structure and sub structure. This is what the prototype shows. Caching needs 
> to be accessed via a hashmap get or other lookup. Metadata and the traversing 
> structure will be navigated in parallel
> - expose a structure that is specialized to a single property or container 
> unwrapping aspect. The structures will be spread across and embedded in the 
> Metadata
> 
> 
> Another angle:
> - create a traversable object per payload to carry it (sharing metadata info 
> per type)
> - have a stateless traversable object that is provided the payload for each 
> access
> 
> The former seems better as it does not create a traversable object per object 
> navigated.
> The latter is better for payloads that need parsing or are better at 
> sequential access since state could be cached.
> 
> We need to discuss that and know where DocumentBuilder is going to properly 
> design this API.
> 
> Emmanuel
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev 
> 
> 

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MariaDB-specific Dialects

[Sanne Grinovero]

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 can't automatically figure out if the connected database is a
MariaDB or a MySQL instance?

That would be sad. I hope you can find a solution :)

>
> Relatedly, I wonder if we should begin to remove the Dialects we have marked
> as deprecated and whether we should consider a  "legacy" repo where we can
> dump these (as well as other removed features - Javassist support e.g.).
> The expectation would be no continued development, but would make them  more
> readily available to users who still needed them as opposed to simply
> dropping them completely.  We could even alter the license of those classes
> to be less restrictive than LGPL in terms of contributing back changes.
>
>
> On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero  wrote:
>>
>> +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 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 Hibernate user to figure out
>> > that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
>> > microsecond precision which have been available since MariaDB 5.3:
>> >
>> > https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
>> >
>> > Let me know what you think.
>> >
>> > Vlad
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev