Re: [hibernate-dev] Hibernate site SEO optimization
Let's revive this discussion and work on getting a solid plan in place. I think the first question is whether we can get the proper header updates in place in the current doc server. As pointed out, we do not control the root of that machine. Additionally we do not even have our own doc root, meaning changes we make might affect others and conversely as well. And if we can, do we want to? If we can't or would simply prefer to host the docs ourselves as part of hibernate.org, then we have a bunch of other things to figure out. Personally I worry about our release builds having to deal with a different GitHub repo (hibernate.org). -- View this message in context: http://hibernate-development.74578.x6.nabble.com/hibernate-dev-Hibernate-site-SEO-optimization-tp839p1332.html Sent from the Hibernate Development mailing list archive at Nabble.com. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Eager fetch and duplicates of collection elements
Hi,
I understand that $subject is a known source of confusion for people
when working with HQL/criteria queries and not applying something like
DistinctRootEntityResultTransformer.
I am seeing the same behaviour though when getting a root entity by id
and join-fetching two (nested) collections. That's my model:
@Entity
public class Parent {
@Id @GeneratedValue
private Long id;
@OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
@JoinColumn(name = "parent_id")
private List children = new ArrayList<>();
}
@Entity
public class Child {
@Id @GeneratedValue
private Long id;
@ElementCollection(fetch=FetchType.EAGER)
@JoinTable(name = "Child_Properties")
@MapKeyColumn(name = "key")
@Column(name = "value")
private Map properties = new HashMap<>();
}
I am persisting a parent with one Child which has three "properties"
entries. Loading the Parent by id yields three elements in the
"children" list:
Parent loaded = session.get( Parent.class, 123 );
assert 1 == loaded.getConfigurations().size(); //
Re: [hibernate-dev] Eager fetch and duplicates of collection elements
Hi,
True. I also wondered why don't we use the DISTINCT as the default
mechanism.
While the underlying SQL would return a result-set according to the total
number of joined relations, we are building the entity tree hierarchy and
I don's see why a user would be interested in getting duplicate root entity
objetc references.
If I want to fetch the parent entity along with all its children, then I'd
rather expect to see distinct parent objects than an object reference for
each child entity.
Vlad
On Thu, Feb 11, 2016 at 3:48 PM, Gunnar Morling
wrote:
> Hi,
>
> I understand that $subject is a known source of confusion for people
> when working with HQL/criteria queries and not applying something like
> DistinctRootEntityResultTransformer.
>
> I am seeing the same behaviour though when getting a root entity by id
> and join-fetching two (nested) collections. That's my model:
>
> @Entity
> public class Parent {
>
> @Id @GeneratedValue
> private Long id;
>
> @OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
> @JoinColumn(name = "parent_id")
> private List children = new ArrayList<>();
> }
>
> @Entity
> public class Child {
>
> @Id @GeneratedValue
> private Long id;
>
> @ElementCollection(fetch=FetchType.EAGER)
> @JoinTable(name = "Child_Properties")
> @MapKeyColumn(name = "key")
> @Column(name = "value")
> private Map properties = new HashMap<>();
> }
>
> I am persisting a parent with one Child which has three "properties"
> entries. Loading the Parent by id yields three elements in the
> "children" list:
>
> Parent loaded = session.get( Parent.class, 123 );
> assert 1 == loaded.getConfigurations().size(); //
Re: [hibernate-dev] Eager fetch and duplicates of collection elements
We can make that change in SQM, but its not an option to change that
before.
But Gunnar your load use case would be a bug if true
On Thu, Feb 11, 2016, 7:55 AM Vlad Mihalcea wrote:
> Hi,
>
> True. I also wondered why don't we use the DISTINCT as the default
> mechanism.
> While the underlying SQL would return a result-set according to the total
> number of joined relations, we are building the entity tree hierarchy and
> I don's see why a user would be interested in getting duplicate root entity
> objetc references.
>
> If I want to fetch the parent entity along with all its children, then I'd
> rather expect to see distinct parent objects than an object reference for
> each child entity.
>
> Vlad
>
> On Thu, Feb 11, 2016 at 3:48 PM, Gunnar Morling
> wrote:
>
> > Hi,
> >
> > I understand that $subject is a known source of confusion for people
> > when working with HQL/criteria queries and not applying something like
> > DistinctRootEntityResultTransformer.
> >
> > I am seeing the same behaviour though when getting a root entity by id
> > and join-fetching two (nested) collections. That's my model:
> >
> > @Entity
> > public class Parent {
> >
> > @Id @GeneratedValue
> > private Long id;
> >
> > @OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
> > @JoinColumn(name = "parent_id")
> > private List children = new ArrayList<>();
> > }
> >
> > @Entity
> > public class Child {
> >
> > @Id @GeneratedValue
> > private Long id;
> >
> > @ElementCollection(fetch=FetchType.EAGER)
> > @JoinTable(name = "Child_Properties")
> > @MapKeyColumn(name = "key")
> > @Column(name = "value")
> > private Map properties = new HashMap<>();
> > }
> >
> > I am persisting a parent with one Child which has three "properties"
> > entries. Loading the Parent by id yields three elements in the
> > "children" list:
> >
> > Parent loaded = session.get( Parent.class, 123 );
> > assert 1 == loaded.getConfigurations().size(); //
Re: [hibernate-dev] Eager fetch and duplicates of collection elements
Filed bug https://hibernate.atlassian.net/browse/HHH-10519; Reproducer
is at
https://github.com/gunnarmorling/hibernate-test-case-templates/commit/3c5507755f83039fe40eac7daaa9f1060d97e426.
--Gunnar
2016-02-11 15:13 GMT+01:00 Steve Ebersole :
> We can make that change in SQM, but its not an option to change that
> before.
>
> But Gunnar your load use case would be a bug if true
>
>
> On Thu, Feb 11, 2016, 7:55 AM Vlad Mihalcea wrote:
>>
>> Hi,
>>
>> True. I also wondered why don't we use the DISTINCT as the default
>> mechanism.
>> While the underlying SQL would return a result-set according to the total
>> number of joined relations, we are building the entity tree hierarchy and
>> I don's see why a user would be interested in getting duplicate root
>> entity
>> objetc references.
>>
>> If I want to fetch the parent entity along with all its children, then I'd
>> rather expect to see distinct parent objects than an object reference for
>> each child entity.
>>
>> Vlad
>>
>> On Thu, Feb 11, 2016 at 3:48 PM, Gunnar Morling
>> wrote:
>>
>> > Hi,
>> >
>> > I understand that $subject is a known source of confusion for people
>> > when working with HQL/criteria queries and not applying something like
>> > DistinctRootEntityResultTransformer.
>> >
>> > I am seeing the same behaviour though when getting a root entity by id
>> > and join-fetching two (nested) collections. That's my model:
>> >
>> > @Entity
>> > public class Parent {
>> >
>> > @Id @GeneratedValue
>> > private Long id;
>> >
>> > @OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
>> > @JoinColumn(name = "parent_id")
>> > private List children = new ArrayList<>();
>> > }
>> >
>> > @Entity
>> > public class Child {
>> >
>> > @Id @GeneratedValue
>> > private Long id;
>> >
>> > @ElementCollection(fetch=FetchType.EAGER)
>> > @JoinTable(name = "Child_Properties")
>> > @MapKeyColumn(name = "key")
>> > @Column(name = "value")
>> > private Map properties = new HashMap<>();
>> > }
>> >
>> > I am persisting a parent with one Child which has three "properties"
>> > entries. Loading the Parent by id yields three elements in the
>> > "children" list:
>> >
>> > Parent loaded = session.get( Parent.class, 123 );
>> > assert 1 == loaded.getConfigurations().size(); //
[hibernate-dev] documentation translations
The translations of the ORM documentation (at least) is completely out of date. Has been for many years. To the point where we stopped even publishing translations. So at this point, as we migrate to Asciidoc(tor) and make changes to doc hosting do we plan for eventual translations? Or do we move forward assuming no translations? At the end of the day this is a simple point in that I need to know whether to preserve the en-US directory in the publishing or not. But if we do not plan on having translations, it seems odd to even deal with these language dirs. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] documentation translations
I think it's nearly impossible to keep documentation to date across several languages. If the users haven't complained that we didn't maintain the non-English docs, I'd suppose we could simply focus on the English version only. Google Chome does a decent job when translating articles from English to other languages anyway. Vlad On Thu, Feb 11, 2016 at 6:57 PM, Steve Ebersole wrote: > The translations of the ORM documentation (at least) is completely out of > date. Has been for many years. To the point where we stopped even > publishing translations. > > So at this point, as we migrate to Asciidoc(tor) and make changes to doc > hosting do we plan for eventual translations? Or do we move forward > assuming no translations? > > At the end of the day this is a simple point in that I need to know whether > to preserve the en-US directory in the publishing or not. But if we do not > plan on having translations, it seems odd to even deal with these language > dirs. > ___ > 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] documentation translations
Ok, then I will drop the 'en-US' part from the path. A related discussion about the 'html' versus 'html_single' paths. Currently the asciidoctor outputs are put into the 'html' path, but what goes there is what is normally considered html-single. At the moment Asciidoctor does not offer chunked html rendering, hence why we only render the one "html single" output. But to be consistent, I think we should rename the "html" in these asciidoc paths to "html_single". I have changed the build for 5.1 to only generate one docbook doc (integrationGuide) until we get that one migrated. That way we have consistency between docbook and asciidoc outputs but also in what is normal usage. On Thu, Feb 11, 2016 at 11:46 AM Vlad Mihalcea wrote: > I think it's nearly impossible to keep documentation to date across > several languages. > If the users haven't complained that we didn't maintain the non-English > docs, > I'd suppose we could simply focus on the English version only. > > Google Chome does a decent job when translating articles from English to > other languages anyway. > > Vlad > > On Thu, Feb 11, 2016 at 6:57 PM, Steve Ebersole > wrote: > >> The translations of the ORM documentation (at least) is completely out of >> date. Has been for many years. To the point where we stopped even >> publishing translations. >> >> So at this point, as we migrate to Asciidoc(tor) and make changes to doc >> hosting do we plan for eventual translations? Or do we move forward >> assuming no translations? >> >> At the end of the day this is a simple point in that I need to know >> whether >> to preserve the en-US directory in the publishing or not. But if we do >> not >> plan on having translations, it seems odd to even deal with these language >> dirs. >> > ___ >> 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] documentation translations
Hi, > Ok, then I will drop the 'en-US' part from the path. +1 > But to be consistent, I think we should rename the "html" in these asciidoc > paths to "html_single". but why even make this distinction? Just 'html' would work for me as well. --Hardy pgp0HN7837BKS.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] documentation translations
On Thu, Feb 11, 2016 at 2:38 PM Hardy Ferentschik wrote: > Hi, > > > Ok, then I will drop the 'en-US' part from the path. > > +1 > > > But to be consistent, I think we should rename the "html" in these > asciidoc > > paths to "html_single". > > but why even make this distinction? Just 'html' would work for me as well. > Because we do have some that have both.And ultimately all of them will once Asciidoctor supports it chunked output. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
