Yes, finer grained control would be a great thing. I don't believe there's a JIRA request for it yet.
Could you please create one Stephane?
Clinton
On 6/21/05, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
I came across a slightly annoying issue a couple of minutes ago with
iBatis/cglib.
For instance I'm serializing data over the network that have cglib
instrumented classes (relations)
When lazyloading is enabled (default), it could seem obvious that it
does not make sense to serialize your data. You could well have
bazillions of objects, yet this is what lazy loading is all about
preventing.
Yet it is not always true.
You may know, that your relationships are not in the form 1:bazillion
but more like 1:4 (replace 4 by your favorite 'less than 10' number)
with very lightweights objects .
To workaround this, you can AFAIK:
1) disable applicationw-wide lazy loading via <settings/> (big side-effect)
2) implements your own serialization mechanism (annoying)
At the moment I did (2), where I'm basically doing:
class Parent {
transient ArrayList children = new ArrayList();
... serializable fields...
...
private void writeObject(ObjectOutputStream out) throws IOException {
out.defaultWriteObject();
ArrayList list = new ArrayList(children);
out.writeObject(list);
}
private void readObject(ObjectInputStream in) throws
ClassNotFoundException, IOException {
in.defaultReadObject();
children = (ArrayList)in.readObject();
}
}
Yet, I was wondering if it would make sense to fine-grained control over
the lazy-loading. For instance, having a per-statement lazy-loading flag
where dependent requests (like in the case of n+1 selects) would inherit
this flag.
Just some thoughts straight without thinking too much.
Any comments ?
Stéphane
