Unfortunately my boss is not OK with this solution. Thank you in any case,
I will try to do per thread copying.

One more solution could be to mimic the functionality of database on OJB
level. That is to specify the default value that will be assigned to a field
at creation of the object. I could have done it in the class's constructor
but think this should be externalized in a class config file like
init-value:

<field-descriptor
        name="dateChanged"
        column="DATECH"
        jdbc-type="DATE"
        init-value = "0001-01-01" />

-Sergey



-----Original Message-----
From: Andy Malakov [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 04, 2004 2:42 PM
To: [EMAIL PROTECTED]
Subject: Re: insert object, and don't specify a value for one of the fields

That was friendly advise. At least in my case I found that my boss/our
customers doesn't care of such details providing that their
requirements are still OK. OJB is clearly missing fine-grained control here.
Thus any workaround would be ugly.

If all inserts happen in separated context you may also consider local patch
to class registry (remove that attribute from
per-thread copy of class metadata).



----- Original Message ----- 
From: "Manukyan, Sergey" <[EMAIL PROTECTED]>
To: "'OJB Users List'" <[EMAIL PROTECTED]>
Sent: Wednesday, February 04, 2004 2:22 PM
Subject: RE: insert object, and don't specify a value for one of the fields


> Maybe I should give you my manager's phone number and you will explain it
to
> him ... ;) I think in anyway we should have a mechanism to control what
> fields take part in operations.
> Regards. Sergey.
>
>
>
> -----Original Message-----
> From: Andy Malakov [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 04, 2004 2:24 PM
> To: OJB Users List
> Subject: Re: insert object, and don't specify a value for one of the
fields
>
> Simplest solution may be to change business logic. Since you want it to be
> writable from OJB side, who said "dateChanged" should be
> initially set by database? Sorry :-)
>
> ----- Original Message ----- 
> From: "Manukyan, Sergey" <[EMAIL PROTECTED]>
> To: "'OJB Users List'" <[EMAIL PROTECTED]>
> Sent: Wednesday, February 04, 2004 1:31 PM
> Subject: RE: insert object, and don't specify a value for one of the
fields
>
>
> > Hi Armin,
> >
> > If I declare this field as readonly, then it will be always readonly,
but
> I
> > need to update on UPDATE operations, and omit on INSERT operations.
> > I guess the possible solution I am seeking for could be to declare
> something
> > like this:
> >
> > <field-descriptor
> > name="dateChanged"
> > column="DATECH"
> > jdbc-type="DATE"
> > use-database-default-if-null-on-insert-operations = "true" />
> >
> > Or can I somehow dynamically exclude this field from participating in
> > operation, whatever this operation might be? Similar to
ObjectModification
> > class mechanism, but that will exclude this field from operation only
for
> > this Broker?
> >
> > I know I can dynamically change the class descriptor and set this field
to
> > anonymous and then revert it back to normal, but I am afraid this will
> > impact other Brokers operations with this class,
> >
> > -Sergey
> >
> >
> >
> > -----Original Message-----
> > From: Armin Waibel [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 04, 2004 11:30 AM
> > To: OJB Users List
> > Subject: Re: insert object, and don't specify a value for one of the
> fields
> >
> > Hi Sergey,
> >
> > Manukyan, Sergey wrote:
> >
> > > Folks,
> > >
> > > The thing is I need to insert a record where for one of the fields I
> want
> > to
> > > omit value, not specify at all, not even null, nothing. So that in
> INSERT
> > > operation it will not be present at all and will be populated by the
> > default
> > > value from database. Is there a way how I can do that?
> > >
> >
> > you can try to declare field as access="readonly".
> >
> > regards,
> > Armin
> >
> > > Thank you,
> > > -Sergey
> > >
> > > **********************
> > > ** LEGAL DISCLAIMER **
> > > **********************
> > >
> > > This E-mail message and any attachments may contain
> > > legally privileged, confidential or proprietary
> > > information. If you are not the intended recipient(s),
> > > or the employee or agent responsible for delivery of
> > > this message to the intended recipient(s), you are
> > > hereby notified that any dissemination, distribution
> > > or copying of this E-mail message is strictly
> > > prohibited. If you have received this message in
> > > error, please immediately notify the sender and
> > > delete this E-mail message from your computer.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to