Hi Colin,
Colin Kilburn wrote:
Hello,
I am using optimistic locking for a few classes/tables in my
application. However, in certain circumstances when my application
starts up, I want to disable optimistic locking for the lifetime of the
application. I have tried to modify the repository
Hello,
I am using optimistic locking for a few classes/tables in my
application. However, in certain circumstances when my application
starts up, I want to disable optimistic locking for the lifetime of the
application. I have tried to modify the repository metadata at
runtime, but I stil
On 9/7/05, Daniel Perry <[EMAIL PROTECTED]> wrote:
> True.
>
> Although surely if you're passing an item through the conversion, it
> requires the conversion every time, so the default behaviour *should* never
> happen. So, checking the extra types should only impact cases where you've
> not used
True.
Although surely if you're passing an item through the conversion, it
requires the conversion every time, so the default behaviour *should* never
happen. So, checking the extra types should only impact cases where you've
not used INTEGER. So, no penalty (except a few more bytes in class fil
On 9/7/05, Daniel Perry <[EMAIL PROTECTED]> wrote:
> Hmm... What about modifying Boolean2IntFeild itself so it handles both:
Yes, this would be possible but the instanceof's have a possibly
significant runtime cost, esp. since you would want to also handle
Short, Long and possibly Character as
Hmm... What about modifying Boolean2IntFeild itself so it handles both:
private static Byte B_TRUE = new Byte(1);
public Object sqlToJava(Object source)
{
if (source instanceof Integer)
{
if (source.equals(I_TRUE))
{
return Boole
On 9/7/05, Daniel Perry <[EMAIL PROTECTED]> wrote:
> The following works fine:
>
> /**
> * @ojb.field jdbc-type="INTEGER"
> *
> conversion="org.apache.ojb.broker.accesslayer.conversions.Boolean2IntFieldCo
> nversion"
> */
> protected boolean deleted;
>
> But, if you use:
>
> @ojb.field jdbc-
The following works fine:
/**
* @ojb.field jdbc-type="INTEGER"
*
conversion="org.apache.ojb.broker.accesslayer.conversions.Boolean2IntFieldCo
nversion"
*/
protected boolean deleted;
But, if you use:
@ojb.field jdbc-type="TINYINT"
Then, xdoclet does as it should:
And ojb dies (although
Hi Joan,
I think this is fixed in CVS (will be included in next version of OJB) - see
http://issues.apache.org/jira/browse/OJB-3
If possible, please try latest version from CVS (use OJB 1.0.x branch:
OJB_1_0_RELEASE, trunk is unstable OJB 1.x).
regards,
Armin
JML (Brujula) wrote:
I need help
On 9/7/05, Daniel Perry <[EMAIL PROTECTED]> wrote:
> What i mean, is that you cant do:
>
> name="deleted"
> column="deleted"
> jdbc-type="TINYINT"
> conversion="org.apache.ojb.broker.accesslayer.conversions.Boolean2IntFieldCo
> nversion"/>
>
> It would make sense to use tinyint for booleans
Daniel Perry wrote:
> What i mean, is that you cant do:
I see.
> Problem is... i am using xdoclet to make the repository and torque to make
> the database. So, i have to use INTEGER in the xdoclet comment, so it ends
> up as integer in the database. I previously have put it as INTEGER then
> us
What i mean, is that you cant do:
It would make sense to use tinyint for booleans as they only really need
1bit!
Problem is... i am using xdoclet to make the repository and torque to make
the database. So, i have to use INTEGER in the xdoclet comment, so it ends
up as integer in the databa
12 matches
Mail list logo
