ho to deal setting property in database

ho to deal setting property in database

Post by Yin Min » Mon, 29 Apr 2002 10:16:56



I wrote a simply class, its properties are stored in database and it
has some typical g/setter methods, I met a problem about how to rite
these setter methods?
I mean, someone call a method, say setName(newName), then how to save
this modification to database?
1. from Jive, it save all the properties to db in each setter method
Quote:>setName(newName){
>    this.name=newName;
>    saveToDB();
>}
>saveToDB(){
>    //get connection and update all columns in database
>}

you see, it's inefficient, if I want to modify ten properties, it has
to update database for ten times, and each time it update all the
properties. and, the most important, if the saveToDB() is fail in
SQLException or other reasons, the properties, which have been
modified to newValue, will differ from the real ones stored in
database. to avoid that, I have to call loadFromDB() once after
saveToDB().

so how to avoid this problem and improve efficiency?

I think that I can use separate saveXXXToDB() instead of one
saveToDB(). for instance:

Quote:>setName(newName) {
>    try{
>            saveNameToDB(newName); //if failed, jump to catch()
>            this.name=newName;
>    }catch(SQLException se){
>            //if save to db failed, I won't modify this.name
>    }
>}

but it's also inefficient. if I want to modify many properties I have
to connect to db and update records for many times.
 
 
 

ho to deal setting property in database

Post by Chris Sarge » Tue, 30 Apr 2002 17:32:57


I'm not sure that it's possible to write a class that maintains the
set of properties AND manages the database-access (the way you want
it) at the same time.

I'd keep your properties class simple, and let the client of the class
worry about when to save/load to the database (see below).

Hope this helps.

- sarge

class Stuff
{
    private String thisProperty = ...
    private int thatProperty = ...
    // etc...

    // Setters:
    public void setThisProperty( String ... )
    public void setThatProperty( int ... )
    // etc...

    // Data access:
    public void load() ...
    public void save() ...

Quote:}

This could be used as follows:

// Get defaults from DB
Stuff stuff = new Stuff();
stuff.load();

// Fiddle with the properties
stuff.setThisProperty( ... )
stuff.setThatProperty( ... )
// etc...

// Commit to DB
stuff.save();

 
 
 

ho to deal setting property in database

Post by Simon Gibb » Wed, 01 May 2002 04:30:10



> I'm not sure that it's possible to write a class that maintains the
> set of properties AND manages the database-access (the way you want
> it) at the same time.

> I'd keep your properties class simple, and let the client of the class
> worry about when to save/load to the database (see below).

D'oh, my final yeah project does exactly this. Although I haven't yet
tested the code what I am doing is creating a super-class for all my
"beans". The baseclass has a private method called updateFeild which
take a String field name and a value.

The method is overloaded a few times to give support for int String and
Date objects (and translates between java.sql.Data and java.util.Date of
the fly) this is all I need at the mo. Each setter calls an UPDATE
statement via the conveniance methods each time its called. The getter
methods just reference the "in-Java" atributes rather than talkin to the
DB and I tend to regard them as a cache.

I found that there was no guaranteed way to make sure bean instances in
two threads were uptodate with each other unless I made db updates on
the fly. What I have at the moment still isn't foolproof, but to get any
better I'd have to take steps to ensure that each thread actually
refered to the same instance and where neccesary use events to monitor
property changes. This is all nicely supported in Java, but with only a
few weeks left until crunch time its not strictly neccessary especially
as the life of the beans is so short in my application and as differnt
users will be using different records anyway. i.e. working on their own
stuff.

Am I mad?

Simon

--

unchecked (it's usually spam). To reply substitute "usenet"
with "mail", or any 1 word appropriate to the topic.

Web Site: http://www.simongibbs.co.uk/

"Anyone who speaks German can't be a bad man!" Female
Jury Member, Sideshow Bob's Parole Hearing

 
 
 

ho to deal setting property in database

Post by Yin Min » Wed, 01 May 2002 12:15:08


On Mon, 29 Apr 2002 20:30:10 +0100, Simon Gibbs


>> I'm not sure that it's possible to write a class that maintains the
>> set of properties AND manages the database-access (the way you want
>> it) at the same time.

>> I'd keep your properties class simple, and let the client of the class
>> worry about when to save/load to the database (see below).

>D'oh, my final yeah project does exactly this. Although I haven't yet
>tested the code what I am doing is creating a super-class for all my
>"beans". The baseclass has a private method called updateFeild which
>take a String field name and a value.

>The method is overloaded a few times to give support for int String and
>Date objects (and translates between java.sql.Data and java.util.Date of
>the fly) this is all I need at the mo. Each setter calls an UPDATE
>statement via the conveniance methods each time its called. The getter
>methods just reference the "in-Java" atributes rather than talkin to the
>DB and I tend to regard them as a cache.

Hey, you mean in each setter method you call a updateField() and
update ALL the properties?

- Show quoted text -

Quote:

>I found that there was no guaranteed way to make sure bean instances in
>two threads were uptodate with each other unless I made db updates on
>the fly. What I have at the moment still isn't foolproof, but to get any
>better I'd have to take steps to ensure that each thread actually
>refered to the same instance and where neccesary use events to monitor
>property changes. This is all nicely supported in Java, but with only a
>few weeks left until crunch time its not strictly neccessary especially
>as the life of the beans is so short in my application and as differnt
>users will be using different records anyway. i.e. working on their own
>stuff.

>Am I mad?

>Simon

 
 
 

ho to deal setting property in database

Post by Yin Min » Wed, 01 May 2002 12:15:10




>I'm not sure that it's possible to write a class that maintains the
>set of properties AND manages the database-access (the way you want
>it) at the same time.

>I'd keep your properties class simple, and let the client of the class
>worry about when to save/load to the database (see below).

>Hope this helps.

A good approach. Only the client know when and whether he want ot
modify a bean. But will it cause multi-thread problem? Becuase it
doesn't modify the real property immediately.
Quote:

>- sarge

>class Stuff
>{
>    private String thisProperty = ...
>    private int thatProperty = ...
>    // etc...

>    // Setters:
>    public void setThisProperty( String ... )
>    public void setThatProperty( int ... )
>    // etc...

>    // Data access:
>    public void load() ...
>    public void save() ...
>}

>This could be used as follows:

>// Get defaults from DB
>Stuff stuff = new Stuff();
>stuff.load();

>// Fiddle with the properties
>stuff.setThisProperty( ... )
>stuff.setThatProperty( ... )
>// etc...

>// Commit to DB
>stuff.save();