Query Parser Redesign
by Steve Ebersole
Andrea, this is in relation to something you asked me on IRC today.
Specifically in regards to FromClause and the fact that it maintains
pointers to parent/children. As I said on IRC there is no intrinsic need
(I do not foresee) for keeping this structure; I really only did that
because FromCauseProcessor needed a stack of FromClauses and the FromClause
itself made a simple place to do that.
However, in later work I ran into minor problems because of that decision.
I need to make a copy of an entire SelectStatement tree. But because the
FromClause is held twice (for non-root FromClauses) in the tree, it makes
it more complicated to do a "simple copy" than it need be. Basically I
need to maintain a "Map<FromClause,FromClause> copy Map" :(
Long story short, I think I might revisit that decision and instead write a
dedicated stack in FromClauseProcessor for this. In the morning... its too
late to start something that ambitious tonight. I'll start that in the
morning, unless someone wants to pick that up in the next few hours before
I get back on line.
9 years, 5 months
Testing Hibernate 5: injecting a Spring managed interceptor
by Guillaume Smet
Hi,
As I have cycles this week and next week, I thought I might as well do some
QA on Hibernate 5.
I'm still in the process of porting our code to 5 atm and I have a pattern
we used before I can't find an elegant way to port on Hibernate 5: this
pattern is used to inject a Spring managed interceptor.
We override the persistence provider to inject the interceptor in the
Hibernate configuration:
https://gist.github.com/gsmet/e8d3003344938b1d327b
I studied the new code for quite some time and I couldn't find a way to
inject my interceptor in 5.
Note that it's a pretty common usage in the Spring managed world.
Thanks for any guidance.
--
Guillaume
9 years, 5 months
Re: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"
by Sanne Grinovero
On 26 August 2015 at 12:28, Davide D'Alto <davide(a)hibernate.org> wrote:
> Can't we keep some secrets tokens on master?
> Or on a separate secret small machine?
>
> This way we can transfer them from master during the creation of the slave.
> Basically, I'm talking about improving the transfert-to-slave script.
That's what I proposed in the previous email, but there are tradeoffs
such as having to maintain more secret keys somewhere. I'm not sure
which approach is the lesser evil ;)
Sanne
>
>> Davide extended this further with tags: see the readme to easily run
> only the tasks related to a specific task (although we should tag all
> tasks, not done yet).
>
> I might now have explained that in the readme, but the Ansible documentation
> is clear: http://docs.ansible.com/ansible/playbooks_tags.html
>
>> FWIW, ECDSA is the future: get a better OS ;-)
>
> +1 :)
>
> Davide
>
> On Wed, Aug 26, 2015 at 12:15 PM, Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>>
>> On 25 August 2015 at 14:15, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>> > Sanne,
>> >
>> > When running Ansible to update the CI slaves on OS X, I get the
>> > following error:
>> >
>> > TASK: [jenkins-slave | Ensure cimaster is a known host]
>> > ***********************
>> > unknown key type ecdsa
>> > fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
>> > 54.174.65.136) returned 255
>> >
>> > Can we use another key type than "ecdsa"? Apparently the SSH coming
>> > with OS X has no support for it (see [1]) and I'd prefer to use the
>> > default version rather than having to install another one.
>>
>> That line though is just a trick to fetch the existing keys so I guess
>> that to change the key type we need to figure out when & how these are
>> generated.
>> I just checked and it seems like we actually generate (and use) RSA
>> keys now; maybe that line is just broken on all platforms (not just on
>> OSX)?
>> When making changes I only run the related portions of the Ansible
>> script, so that might have been broken since a while w/o anyone
>> noticing.
>> Davide extended this further with tags: see the readme to easily run
>> only the tasks related to a specific task (although we should tag all
>> tasks, not done yet).
>>
>> I'm actually quite unhappy with that whole trick to get the generated
>> nodes exchange the keys; it doesn't seem like "the Ansible way" as
>> it's quite procedural, but I couldn't figure a better way other than
>> pre-generate them (and lots of other people have that problem on SO so
>> I'd hope it will improve).
>> Would you prefer us to pre-generate those keys manually and add them
>> to the list of secret tokens which we need to share among maintainers?
>> I was trying to keep the list of keys we all need and the preparation
>> steps minimal, but agree this one might not be worth the complexity.
>>
>> FWIW, ECDSA is the future: get a better OS ;-)
>>
>> Thanks,
>> Sanne
>>
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> > [1]
>> > http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
9 years, 5 months
Ansible set-up, error "unknown key type ecdsa"
by Gunnar Morling
Sanne,
When running Ansible to update the CI slaves on OS X, I get the following error:
TASK: [jenkins-slave | Ensure cimaster is a known host] ***********************
unknown key type ecdsa
fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
54.174.65.136) returned 255
Can we use another key type than "ecdsa"? Apparently the SSH coming
with OS X has no support for it (see [1]) and I'd prefer to use the
default version rather than having to install another one.
Thanks,
--Gunnar
[1] http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
9 years, 5 months