Hi Clinton,
great! this is a good news ;-)
tnx very much
ciao
2010/2/14 Clinton Begin
> K, There were enough people interested, and it only took 10 seconds to add
> support for line breaks and tabs etc. into the inline parameters... so I
> added it.
>
> Clinton
>
>
> On Fri, Feb 5, 2010 at 8
K, There were enough people interested, and it only took 10 seconds to add
support for line breaks and tabs etc. into the inline parameters... so I
added it.
Clinton
On Fri, Feb 5, 2010 at 8:45 AM, Marco Speranza
wrote:
> Hi Clinton,
>
> I totally agree with you when you speak about format but
Hi Clinton,
I totally agree with you when you speak about format but let me
explain better: there are customers QA that impose strict coding rules
- XML files included - and one of them checks if a codeline is
contained in 'n' chars.
Even if nobody agree, in this scenario the QA
could not accept
One change I'd like to see in the mapper file is to allow any ordering
of clauses within a ResultMap. I've gotten tripped up twice because I
put an association clause in the middle of a bunch of result clauses.
Why would I want to do this? To keep the clauses in the same order as
the columns
PS: And yes, I will correct the documentation. That was done because I
don't think it fit on one line.
It should be extremely rare to use the attributes at all, and when you do,
it will be one or two at most...
For example, the following are likely mappings, in order of likelyhood:
*#{some_col
>> because an XML file should not be "formatting-sensitive".
That's not true at all. The XML tags shouldn't be formatting sensitive, but
the content can be. That's our format, that's our requirement.
That said, I'm open to improving the error. But I personally will not
support line breaks in t
Hi Clinton,
So if the #{} syntax will never be removed we have to fix the little
line-break problem, because an XML file should not be
"formatting-sensitive".
Moreover yesterday night I made a simple test-case that reproduces the
example wrote in the iBatis manual (page 26), and the parser raises
These are all great thoughts. As I said, one of them is likely to be
implemented in the future. It's just been deprioritized for now.
Clinton
On Thu, Feb 4, 2010 at 8:42 AM, Simone Tripodi wrote:
> Yep, I forgot the same syntax is used in annotations :)
> BTW, it was just a 2 cents idea, not a
Yep, I forgot the same syntax is used in annotations :)
BTW, it was just a 2 cents idea, not a real proposal.
Cheers,
Simo
http://people.apache.org/~simonetripodi/
On Thu, Feb 4, 2010 at 4:22 PM, Clinton Begin wrote:
> The syntax will never be removed, first because it's the preferred way of
>
The syntax will never be removed, first because it's the preferred way of
the majority, and second, because we need a parameter syntax that is
compatible with other configuration options, like annotations or JSON, etc.
Clinton
On Thu, Feb 4, 2010 at 12:44 AM, Simone Tripodi wrote:
> Hi all guys,
Hi all guys,
sorry but I explained my "2 cents idea" in the wrong way :P
Indeed, in my dreams, I'd completely _remove_ the #{} syntax, IMHO it
should be simpler reading a 100% pure XML SQL map like:
update ORDER_ENTRY.CONTACT
set
DEPT_ID =
STATE_ID =
TIME_ZONE_ID =
instead of
update ORD
On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier wrote:
> On 2/3/2010 3:54 PM, Daryl Stultz wrote:
>
>>
I like this idea, though to keep things consistent, I would just use
>> "parameter" instead of "parameterDef".
>>
>
Right, I just made up parameterDef to indicate is was for defining the
parameter
On 2/3/2010 3:54 PM, Daryl Stultz wrote:
On Wed, Feb 3, 2010 at 3:32 PM, Simone Tripodi mailto:simone.trip...@gmail.com>> wrote:
Forgot to say that, of course, there are cons, like in the sample below:
I misread your first post and was thinking you wanted something like this:
inse
This was actually a very serious consideration for us. I personally like
this design a lot.
FWIW: Parameter maps are in iBATIS 3, but the DTD disables the element.
Primary reason is that it still works exactly like iBATIS 2, which is not
based on named parameters as you've suggested. Before add
On Wed, Feb 3, 2010 at 3:32 PM, Simone Tripodi wrote:
> Forgot to say that, of course, there are cons, like in the sample below:
>
> I misread your first post and was thinking you wanted something like this:
insert into users (id, username, password, department)
values (#{id}, #{user
Forgot to say that, of course, there are cons, like in the sample below:
insert into users (id, username, password)
values (,
)
is much more verbose than:
insert into users (id, username, password)
values (#{id}, #{username}, #{password})
All the best ;)
Simo
http://people
Hi all,
just my 2cents: even if I'm familiar with XML SQL maps, I've always
found the property parameter a little confusing into iBatis, since
adds a new syntax in the XML syntax, indeed I was a great fan of
iBatis2 ParameterMap.
IMHO a "nice to have" in the SQL map is something like:
instea
Hi Clinton,
thanks for your reply, I understand that's a design choice but I sadly
noticed that when the property parameter contains a break line character,
iBatis raises a so generic error that I had to spend a lot of time to
understand what was the cause...
So, yesterday I spent a good part of t
That is by design and will not change. I suggest that when formatting
parameters, put the entire thing on a newline when necessary. It's
far too unreadable if you spit them up.
Clinton
On 2010-02-02, Marco Speranza wrote:
> Hi all Guys,
>
> we have found a little problem on iBatis3.
> We have
19 matches
Mail list logo
