Filters and many to many
by Emmanuel Bernard
In xml to set up a filter on the target table of a many to many, you set
the filter element inside the <many-to-many> element
To support that in annotations, I could do
1.
@Filter (pointing to the association table or the target table if a
@OneToMany @JoinColumn)
@FilterManyToMany (@FilterTargetEntity) (pointing to the association
table or the target table if a @OneToMany @JoinTable | @ManyToMany)
or
2.
@Filter (pointing to the target table)
@FilterJoinTable (pointing to the association table)
I like 2. better, it is more consistent esp when you realize that
@OneToMany can use a join table just by changing an annotation.
2. would require a break to the users playing with @Filter and
associations involving join tables.
WDYT?
Any annotation better name are welcome too.
19 years, 1 month
batch-size algorithm
by Emmanuel Bernard
Currently we create several loaders following a certain algorithm
Why don't we create a single loader of batch-size and duplicate ids in
the in clause to match unfilled parameters
batch-size = 20
uninitialized proxies 17
current algorithm
select * from Table where id in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
select * from Table where id in (11, 12, 13, 14, 15, 16, 17)
current algorithm
select * from Table where id in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 17, 17, 17)
This would reduce the memory footprint and reduce the prepared statement
pool needed
This case is a sample but it shines when people set up a batch-size of
100 since the number of queries triggered can drop from 5 to 1 query for
98 uninitialized proxies
19 years, 1 month
Re: More fun with merging : non-updatable fields
by Josh Moore
Sorry, Christian, didn't get your emails because of a delayed digest
message. And I agree that it can be seen as reasonable behavior. With
saveOrUpdate (as Emmanuel was pointing out) one gets
* in DB: no change
* in memory: (invalid) change
and with these semantics for merge:
* in DB: no change
* in memory: (invalid) change.
Understood. I think there's a case to be made, however, for not
expending extra time for merge to make the in memory representation
invalid. For me it's a part of what "merge" means : "Take the DB
representation and the in-memory representation and produce something
_new_". I.e. I'm expecting to have to deal with that situation.
SaveOrUpdate differs in that I still have my in-memory object
references, so no one should screw with them. Merge is polar opposite.
I'm given new references and have to, somehow, deal with this new state.
My opinion, which is nothing more than that, is : it'd be nice if those
new object references were valid.
But, *shrug*, whatever. If those aren't desired or generally useful
semantics, I'll finish implementing the logic for my MergeEventListener.
I could use some help getting hold of EmbeddedComponentType's metamodel
(see
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907). But
I'll catch Max on irc for that. ;)
Thanks again,
Josh.
P.S. one last thing, Christian. You mentioned "Don't [apply those
values] if you don't want [them]", though there's one case where it's
actually "Then do [appply those values] if you want [them]". Namely on
the reverse side of a bidirectional many-to-one. If you call
child.setParent(parent) and not parent.getChildren().add(child), then
you'll get a parent back which still doesn't have children in it. A bit
freaky the first time you experience it. And no, Hibernate doesn't do
CMR, but it also needn't go out of it's way to NOT do CMR. Cheers.
Christian wrote:
>> This is consistent with the way saveOrUpdate works
>
> And it's perfectly reasonable behavior. If I modify a field value,
> then merge, then take the instance returned by merge, I expect that
> the value is still there in the merged result. That has nothing to do
> with the update/UPDATE behavior of Hibernate.
>> copies _invalid_ values on top of the clean proxied collection, and
>> sends that back to the user.
>
> It does so because you applied these values. Don't do that if you
> don't want it. Thanks to Hibernate your mistake will not end up in
> the database.
Max wrote:
> Yes, Josh - consider especially the situation Christian explained that if
> you merge Xy onto a session you expect the returning object is Xy and not
> Xx.
>
> If you want this behavior (which in some cases I can see the usefullness
> of) you need to have
> a custom merge implementation as you already have.
>
> /max
19 years, 1 month
