Guillaume, thanks for the suggestion. I'll give it a try...
On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet
wrote:
> I would try changing the start of EnhancerImpl#enhance() to:
> ===
> public byte[] enhance(String className, byte[] originalBytes) throws
> EnhancementException {
>
I would try changing the start of EnhancerImpl#enhance() to:
===
public byte[] enhance(String className, byte[] originalBytes) throws
EnhancementException {
//Classpool#describe does not accept '/' in the description name as
it expects a class name. See HHH-12545
final Strin
Thinking more about this, I don't think that ByteBuddy should be able to
do a classloader.getResource() on the class that is being defined
(SLSBPersistenceContexts$$$view5.class). It might be correct for the
getResource call to return null, until after the class is completely
defined.
Would i
On Tue, Mar 26, 2019 at 10:17 AM Sanne Grinovero
wrote:
>
> Why should we not?
>
There is a very compelling reason for that. I'll have to leave it at that.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/li
On Tue, 26 Mar 2019 at 15:08, Steve Ebersole wrote:
>
> On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote:
>>
>> One question: could we benefit from "cascade delete" rules defined in
>> the table structure?
>>
>>
>> If Hibernate ORM was able parse the cascading rules from existing
>> schemas,
On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote:
> One question: could we benefit from "cascade delete" rules defined in
> the table structure?
> If Hibernate ORM was able parse the cascading rules from existing
> schemas, and possibly generate them for new schemas, you could have an
> en
Hi Steve,
this does sound amazing, I think it's certainly worth trying to have
the most efficient strategy chosen on a per-entity base.
One question: could we benefit from "cascade delete" rules defined in
the table structure?
If Hibernate ORM was able parse the cascading rules from existing
sch
Hi,
Here are the minutes of our NoORM IRC meeting:
15:36 < jbott> Meeting ended Tue Mar 26 14:36:05 2019 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:36 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019
https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/6.2E0.20-.20multi-table.20mutation
On Tue, Mar 26, 2019 at 8:25 AM Steve Ebersole wrote:
> While working on 6 I discovered that we maybe do not do the best job in
> regards to "bulk update/delete" queries against multi
Hi Tomek,
I think the pending question now is why ByteBuddy is getting a null
result from the
classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
call.
We have also seen failures for
org.jboss.as.ejb3.SerializationProxyHackImplemen
While working on 6 I discovered that we maybe do not do the best job in
regards to "bulk update/delete" queries against multi-table entities
(secondary tables, joined inheritance, etc). This short-coming exists in
previous versions. Essentially, when a strategy is not explicitly
specified we fall
11 matches
Mail list logo
