Hi,
I recently updated to iBATIS 2.3 and it has broken my "complex" object
maps. Several searches on the mailing list indicate that this is a
problem but without a resolution or further research.
My basic problem: I have an "Image" object, that object has "sizes" and
"flags" properties, ba
I don't count myself as often, but for a 1:M or M:M relationship, I will
often insert multiple rows in a statement.
However, I have no need of the updated row count nor retrieving the PK
for each entry (as they are keyed off of the other relationship).
Larry Meadors wrote:
Am I missing somet
So, do we still need to use the dummy argument to hit the cache? Or is
that unnecessary?
Brandon Goodin wrote:
Yusuf,
If this is not in the FAQ. I think it should be :) I've seen this
happen more than once. Can you check the wiki, see if it is not there
and add it to the FAQ?
Brandon
On 2/2
Gareth Moorst wrote:
I know EXACTLY what you mean.
I'd prefer not to allow anything to have direct access to any of the
Lists inside my data objects, but iBatis has so many other good features
that it was worth changing my data objects slightly.
I always use a public interface for my data obj
Gareth Moorst wrote:
I think this is because of a different issue - when dealing with List
properties, I believe iBatis creates the list, sets it into the parent
class, then adds objects to the lists, so if you are doing any copying
of lists in the setAcc(List accs) method, then you will be cop
bject in my domain class; so I
completely overlooked it.
Thanks for the pointer.
Larry Meadors wrote:
Because whe you serialize Product, the list of Attribute objects
cannot be serialized, so...kaboom.
Make Attribute serializable, and it'll work.
Larry
On 1/13/06, Perry Nguyen <[
I'm having a problem with a simple N+1 selects problem.
I have some objects akin to:
Product implements Serializable {
List attributes;
String id;
}
Attributes {
String name;
String value;
}
and I do something along the lines of
When I go to Serialize Product, I end up with a
my handler and catch the SQLException that
queryWithRowHandler throws.
This works, for now, but it seems like such an ugly solution... Is
there an "approved" method of stopping a RowHandler?
Perry Nguyen wrote:
When using the iBATIS N+1 solution and the max parameter in
queryFo
When using the iBATIS N+1 solution and the max parameter in
queryForList, the behavior is a little bit different than what I would
expect.
The max parameter appears to only address the total rows returned,
however and not the number of elements that would be populated into the
return List.
Larry,
I suppose you're right, the interfaces were an anachronism from the
older design, I think I can refactor the bean interfaces to be the bean
classes now...
Perry Nguyen wrote:
Well,
My situation's a bit complicated, but it has to do with abstracting what
I had for previ
Well,
My situation's a bit complicated, but it has to do with abstracting what
I had for previous entity beans, etc.
Larry Meadors wrote:
Why are you using interfaces for beans?
Larry
On 12/12/05, Perry Nguyen <[EMAIL PROTECTED]> wrote:
I have interfaces for all of my dom
I have interfaces for all of my domain objects, thus, I have something
like this contrived example:
interface Person {
Address getAddress/setAddress
String getName/setName
}
interface Address {
String getStreetName/setStreetName
}
class ConcretePerson {
// implement Person interface
}
12 matches
Mail list logo
