You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by ph...@mail.mcgill.ca on 2004/12/15 05:41:24 UTC
Information about changelog
Can someone provide me with information regarding this entry in the 2.0.8
changelog:
o Probes now always return true for hasReadable/hasWriteable property checks.
Is there a thread about this? Or can someone brief me on it?
I'm looking to upgrade my version of iBatis and I think this modification has
possibly changed the behaviour of the isPropertyAvailable tag. We use this tag
on Map instances as a parameterClass and it doesn't seem to behave like it does
in 2.0.7.
I'd like to dig further, so I was wondering what the intent of this modification
was...
Regards,
Philippe
Re: was Re: Information about changelog - collections vs beans
Posted by Clinton Begin <cl...@gmail.com>.
It's not a showstopper. But the two biggest issues I see are:
1) Type Safety. Doesn't need explaining.
2) Performance. With a JavaBean, each property is essentially method
call and the setting of a reference. With a HashMap, each property
is a method call, an object creation (Entry), a call to .hashCode(), a
possible array resize, a possible rehash, a possible collision and
call to .equals().
Cheers,
Clinton
On Thu, 16 Dec 2004 14:13:04 -0600, Vic Cekvenich <vi...@friendvu.com> wrote:
> I don't see it.
>
> Even w/ Struts at Ziff Davis I allways had my return type set to HashMap
> in iBatis, so I NEVER have to do mapping of fields in xml .
> What I do now in version 2 is returh a HashMap; an ArrayList of HashMaps
> realy. (how ActionScript in Flex worked, they call it associative array
> to bind to a datagrid)
>
> I send iBatis Collections via Hessian (SoA) to Swing Table Model (JDNC)
> and bind it. I deploy via WebStart. Works great.
> Also I can map to a Swing Form Model (jGoodies Form Layout). On a submit
> action I do commons validator in Swing like I would in Struts. So a user
> enters a valid date or whatever. (way ot: I even do dynamic "tiles" in
> Swing w/ add/remove in JPanels).
> Swing actions send in arguments back bia Hessian to Ibatis, also a Map.
> (The dispacher is commons-chain, and Context is a Map).
> No where do I have getters/setters or field mapping.
> Map is a Map of Objects so I know the class/instance Of the Object.
> I can add fields in select statment in ibatis and it just shows up in my
> Swing table w/o any code changes. Losley coupled. Zero mapping of fields
> in XML or in Java.
> Also, if I careate a computed or a fake field, I just put that property
> in the Map.
> Collections good.
>
> (and I have 100 page or so of docs/tutorial on sandraSF.com, if someone
> wants to know more about the "wrong" way. So I locked iBatis to Hessian
> for nice remote service. Also I locked iBatis to JMX so I can flush the
> cache via JMX. And like I said, everything "server side" is Chain, so it
> was easy to implement a remote Lucene DAO. I was planing to donate parts
> to iBatis like JMX and CRUD dispatcher. Not a single bean, get set. Just
> select * and jTable Model that is based on a collection).
>
> In any case, I do not see a problem, but would like to learn what others
> see as a potential problem that I do not see, since I am about to go live...
> So if somone has the time or the will to educate me, I am all ears.
>
> .V
>
>
> Clinton Begin wrote:
>
> >I'll back up Kris on that one. In my experience, the result of Map
> >based domain models isn't pretty.
> >
> >It depends on what you're doing. I'm sure there are places where it
> >works well, but it's certainly the exception, not the rule.
> >
> >Cheers,
> >Clinton
> >
> >On Thu, 16 Dec 2004 16:46:05 +0000, Kris Jenkins
> ><kr...@yahoo.co.uk> wrote:
> >
> >
> >>>>This is just one reason why I always recommend using JavaBeans for 99%
> >>>>of your work. Maps are inconsistent, unpredictable, not typesafe and
> >>>>slow.
> >>>>
> >>>>
> >>>Hm.
> >>>I acctualy feel the other way, that 99% of time, Collections
> >>>implementations such as Map and List are good.
> >>>This way you can be loosley coupled.
> >>>I used to like Beans, but have moved to collections, ( I learned from
> >>>MM Flex.)
> >>>
> >>>
> >>:-/ That doesn't sound like loose coupling to me - that sounds like
> >>throwing away type safety. By that logic, Perl would be inherently
> >>loosely coupled, which it isn't.
> >>
> >>--
> >>Kris Jenkins
> >>Email: kris@jenkster.com
> >>Blog: http://cafe.jenkster.com/
> >>Wiki: http://wiki.jenkster.com/
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> RiA-SoA w/JDNC <http://www.SandraSF.com> forums
> blog <http://www.sandrasf.com/adminBlog>
>
Re: was Re: Information about changelog - collections vs beans
Posted by Clinton Begin <cl...@gmail.com>.
Cool. Sounds very interesting!
Cheers,
Clinton
On Thu, 16 Dec 2004 15:06:30 -0600, Vic Cekvenich <vi...@friendvu.com> wrote:
> I use the OrderdMap (to guarantee order). Since I am doing client side
> Java, performance is a non issue. Each user ("session") has it's own VM
> and own CPU.
>
> On the server side, I use sticky session replicate nothing "design". So
> 6 app (SoA) servers each have their own cache (of their user's queries).
> The CPU is far from the bottleneck, it hardly budges. ( the 1st thing
> that maxes out is the dual gigabit NICs. Next is SQL DB server. Map
> splits... I wish I get to that as a problem. In any case, number of
> columns on a table is few).
>
> .V
>
> Clinton Begin wrote:
>
> >If I recall correctly, commons-collections fast Map implementations
> >are only better for reading, and could possibly be even slower for
> >writing. This also complicates design because you have to find a
> >convenient place to set the Map to "fast mode".
> >
> >Cheers,
> >Clinton
> >
> >
> >
> >
> >On Thu, 16 Dec 2004 14:18:09 -0600, Vic Cekvenich <vi...@friendvu.com> wrote:
> >
> >
> >>Also... I use Apche commons-collections.
> >>
> >>.V
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> RiA-SoA w/JDNC <http://www.SandraSF.com> forums
> blog <http://www.sandrasf.com/adminBlog>
>
Re: was Re: Information about changelog - collections vs beans
Posted by Vic Cekvenich <vi...@friendvu.com>.
I use the OrderdMap (to guarantee order). Since I am doing client side
Java, performance is a non issue. Each user ("session") has it's own VM
and own CPU.
On the server side, I use sticky session replicate nothing "design". So
6 app (SoA) servers each have their own cache (of their user's queries).
The CPU is far from the bottleneck, it hardly budges. ( the 1st thing
that maxes out is the dual gigabit NICs. Next is SQL DB server. Map
splits... I wish I get to that as a problem. In any case, number of
columns on a table is few).
.V
Clinton Begin wrote:
>If I recall correctly, commons-collections fast Map implementations
>are only better for reading, and could possibly be even slower for
>writing. This also complicates design because you have to find a
>convenient place to set the Map to "fast mode".
>
>Cheers,
>Clinton
>
>
>
>
>On Thu, 16 Dec 2004 14:18:09 -0600, Vic Cekvenich <vi...@friendvu.com> wrote:
>
>
>>Also... I use Apche commons-collections.
>>
>>.V
>>
>>
>>
>
>
>
>
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
blog <http://www.sandrasf.com/adminBlog>
Re: was Re: Information about changelog - collections vs beans
Posted by Clinton Begin <cl...@gmail.com>.
If I recall correctly, commons-collections fast Map implementations
are only better for reading, and could possibly be even slower for
writing. This also complicates design because you have to find a
convenient place to set the Map to "fast mode".
Cheers,
Clinton
On Thu, 16 Dec 2004 14:18:09 -0600, Vic Cekvenich <vi...@friendvu.com> wrote:
> Also... I use Apche commons-collections.
>
> .V
>
Re: was Re: Information about changelog - collections vs beans
Posted by Vic Cekvenich <vi...@friendvu.com>.
Also... I use Apche commons-collections.
.V
Re: was Re: Information about changelog - collections vs beans
Posted by Vic Cekvenich <vi...@friendvu.com>.
I don't see it.
Even w/ Struts at Ziff Davis I allways had my return type set to HashMap
in iBatis, so I NEVER have to do mapping of fields in xml .
What I do now in version 2 is returh a HashMap; an ArrayList of HashMaps
realy. (how ActionScript in Flex worked, they call it associative array
to bind to a datagrid)
I send iBatis Collections via Hessian (SoA) to Swing Table Model (JDNC)
and bind it. I deploy via WebStart. Works great.
Also I can map to a Swing Form Model (jGoodies Form Layout). On a submit
action I do commons validator in Swing like I would in Struts. So a user
enters a valid date or whatever. (way ot: I even do dynamic "tiles" in
Swing w/ add/remove in JPanels).
Swing actions send in arguments back bia Hessian to Ibatis, also a Map.
(The dispacher is commons-chain, and Context is a Map).
No where do I have getters/setters or field mapping.
Map is a Map of Objects so I know the class/instance Of the Object.
I can add fields in select statment in ibatis and it just shows up in my
Swing table w/o any code changes. Losley coupled. Zero mapping of fields
in XML or in Java.
Also, if I careate a computed or a fake field, I just put that property
in the Map.
Collections good.
(and I have 100 page or so of docs/tutorial on sandraSF.com, if someone
wants to know more about the "wrong" way. So I locked iBatis to Hessian
for nice remote service. Also I locked iBatis to JMX so I can flush the
cache via JMX. And like I said, everything "server side" is Chain, so it
was easy to implement a remote Lucene DAO. I was planing to donate parts
to iBatis like JMX and CRUD dispatcher. Not a single bean, get set. Just
select * and jTable Model that is based on a collection).
In any case, I do not see a problem, but would like to learn what others
see as a potential problem that I do not see, since I am about to go live...
So if somone has the time or the will to educate me, I am all ears.
.V
Clinton Begin wrote:
>I'll back up Kris on that one. In my experience, the result of Map
>based domain models isn't pretty.
>
>It depends on what you're doing. I'm sure there are places where it
>works well, but it's certainly the exception, not the rule.
>
>Cheers,
>Clinton
>
>On Thu, 16 Dec 2004 16:46:05 +0000, Kris Jenkins
><kr...@yahoo.co.uk> wrote:
>
>
>>>>This is just one reason why I always recommend using JavaBeans for 99%
>>>>of your work. Maps are inconsistent, unpredictable, not typesafe and
>>>>slow.
>>>>
>>>>
>>>Hm.
>>>I acctualy feel the other way, that 99% of time, Collections
>>>implementations such as Map and List are good.
>>>This way you can be loosley coupled.
>>>I used to like Beans, but have moved to collections, ( I learned from
>>>MM Flex.)
>>>
>>>
>>:-/ That doesn't sound like loose coupling to me - that sounds like
>>throwing away type safety. By that logic, Perl would be inherently
>>loosely coupled, which it isn't.
>>
>>--
>>Kris Jenkins
>>Email: kris@jenkster.com
>>Blog: http://cafe.jenkster.com/
>>Wiki: http://wiki.jenkster.com/
>>
>>
>>
>>
>
>
>
>
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
blog <http://www.sandrasf.com/adminBlog>
Re: was Re: Information about changelog - collections vs beans
Posted by Clinton Begin <cl...@gmail.com>.
I'll back up Kris on that one. In my experience, the result of Map
based domain models isn't pretty.
It depends on what you're doing. I'm sure there are places where it
works well, but it's certainly the exception, not the rule.
Cheers,
Clinton
On Thu, 16 Dec 2004 16:46:05 +0000, Kris Jenkins
<kr...@yahoo.co.uk> wrote:
>
> >> This is just one reason why I always recommend using JavaBeans for 99%
> >> of your work. Maps are inconsistent, unpredictable, not typesafe and
> >> slow.
> >
> > Hm.
> > I acctualy feel the other way, that 99% of time, Collections
> > implementations such as Map and List are good.
> > This way you can be loosley coupled.
> > I used to like Beans, but have moved to collections, ( I learned from
> > MM Flex.)
>
>
> :-/ That doesn't sound like loose coupling to me - that sounds like
> throwing away type safety. By that logic, Perl would be inherently
> loosely coupled, which it isn't.
>
> --
> Kris Jenkins
> Email: kris@jenkster.com
> Blog: http://cafe.jenkster.com/
> Wiki: http://wiki.jenkster.com/
>
>
Re: was Re: Information about changelog - collections vs beans
Posted by Kris Jenkins <kr...@yahoo.co.uk>.
>> This is just one reason why I always recommend using JavaBeans for 99%
>> of your work. Maps are inconsistent, unpredictable, not typesafe and
>> slow.
>
> Hm.
> I acctualy feel the other way, that 99% of time, Collections
> implementations such as Map and List are good.
> This way you can be loosley coupled.
> I used to like Beans, but have moved to collections, ( I learned from
> MM Flex.)
:-/ That doesn't sound like loose coupling to me - that sounds like
throwing away type safety. By that logic, Perl would be inherently
loosely coupled, which it isn't.
--
Kris Jenkins
Email: kris@jenkster.com
Blog: http://cafe.jenkster.com/
Wiki: http://wiki.jenkster.com/
was Re: Information about changelog - collections vs beans
Posted by Vic Cekvenich <vi...@friendvu.com>.
Clinton Begin wrote:
>
>This is just one reason why I always recommend using JavaBeans for 99%
>of your work. Maps are inconsistent, unpredictable, not typesafe and
>slow.
>
>
>
Hm.
I acctualy feel the other way, that 99% of time, Collections
implementations such as Map and List are good.
This way you can be loosley coupled.
I used to like Beans, but have moved to collections, ( I learned from
MM Flex.)
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
blog <http://www.sandrasf.com/adminBlog>
RE: Information about changelog
Posted by Philippe Laflamme <ph...@mail.mcgill.ca>.
Hi Clinton,
Thanks for the info.
> This is just one reason why I always recommend using JavaBeans
> for 99% of your work. Maps are inconsistent, unpredictable,
> not typesafe and slow.
I agree. Typesafety is a major issue when dealing with databases. If you're
not careful, you end up comparing numerics with strings and vice-versa...
Our use of Maps is very limited. We build all our complex queries based on
JavaBean properties (especially for typesafety). These queries usually need
to be called twice: one for counting the number of results, the other to get
the actual results.
Our view is that the call to a statement as a "count query" should not be
part of the search criteria. To solve this we use Maps in which we put the
search criteria (JavaBean) and another property that states whether the
statement should build a "count query" or not. This other property is only
present when the call is a "count query", so the test is made using the
isPropertyAvailable tag.
We can easily modify our statements to use another tag for testing this
property. I'm wondering, what's your take on the isPropertyAvailable tag
since it's no longer useful? Will it be deprecated, removed or adjusted?
Thanks a bunch,
Philippe
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: December 15, 2004 9:48 AM
To: philippe.laflamme@mail.mcgill.ca
Cc: ibatis-user-java@incubator.apache.org
Subject: Re: Information about changelog
Ewww.....yes. This was causing inconsistent behaviour between parameter
maps and result maps and it was therefore necessary to simply always return
true. Basically a Map doesn't have properties and you can always set any
value.
This is just one reason why I always recommend using JavaBeans for 99% of
your work. Maps are inconsistent, unpredictable, not typesafe and slow.
Cheers,
Clinton
On Tue, 14 Dec 2004 23:41:24 -0500, philippe.laflamme@mail.mcgill.ca
<ph...@mail.mcgill.ca> wrote:
> Can someone provide me with information regarding this entry in the
> 2.0.8
> changelog:
>
> o Probes now always return true for hasReadable/hasWriteable property
> checks.
>
> Is there a thread about this? Or can someone brief me on it?
>
> I'm looking to upgrade my version of iBatis and I think this
> modification has possibly changed the behaviour of the
> isPropertyAvailable tag. We use this tag on Map instances as a
> parameterClass and it doesn't seem to behave like it does in 2.0.7.
>
> I'd like to dig further, so I was wondering what the intent of this
> modification was...
>
> Regards,
> Philippe
>
Re: Information about changelog
Posted by Clinton Begin <cl...@gmail.com>.
Ewww.....yes. This was causing inconsistent behaviour between
parameter maps and result maps and it was therefore necessary to
simply always return true. Basically a Map doesn't have properties
and you can always set any value.
This is just one reason why I always recommend using JavaBeans for 99%
of your work. Maps are inconsistent, unpredictable, not typesafe and
slow.
Cheers,
Clinton
On Tue, 14 Dec 2004 23:41:24 -0500, philippe.laflamme@mail.mcgill.ca
<ph...@mail.mcgill.ca> wrote:
> Can someone provide me with information regarding this entry in the 2.0.8
> changelog:
>
> o Probes now always return true for hasReadable/hasWriteable property checks.
>
> Is there a thread about this? Or can someone brief me on it?
>
> I'm looking to upgrade my version of iBatis and I think this modification has
> possibly changed the behaviour of the isPropertyAvailable tag. We use this tag
> on Map instances as a parameterClass and it doesn't seem to behave like it does
> in 2.0.7.
>
> I'd like to dig further, so I was wondering what the intent of this modification
> was...
>
> Regards,
> Philippe
>