Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

how to avoid this issue

 
Samanthi perera
Ranch Hand
Posts: 510
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in Hibernating if we add some instance varible to our class , we have to add clume to the database.
anyway if we adding more varibles we have to change the database each time.
How to get rid of this issue?
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Samanthi, please use descriptive subject messages. Pretty much every post on JavaRanch is intended to help someone solve some type of issue.

Also, use real words. I do not know what a clume is?

-Cameron McKenzie
 
Mike Keith
author
Ranch Hand
Posts: 304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, if you asked a doctor he/she would probably tell you not to add instance variables...

But since IANAD (I am not a doctor) I'll play along. Let's assume for a second that you really do need to add an instance variable, but you don't want to add a new column to the database. Where would you expect the new variable state to be persistently stored? You can't share an existing column that you are already storing existing instance variable state in (okay, you can, but it becomes trickier and you generally don't really want to do that). If you are renaming a variable "foo" to "bar" then you could certainly override the new default of "bar" by using a @Column(name="FOO") annotation on your new "bar" variable, and you would be reusing the column from the previous (now renamed) instance variable. Of course you would end up with a schema that was rather mismatched with your object model, something that is quite common when the db already exists but not really necessary when you are creating the db for the application.

If you have the luxury of writing a new application with a new database schema then you might as well just use schema generation and not even give much thought to what the schema looks like while you are in development and testing. Then, when you get closer to the end of the dev cycle, and you aren't making design changes to your classes you get to the stage of fine-tuning your db schema and mappings and every data schema change matters (see comments in Advantages of ORM thread).

On the other hand, if you are mapping to an existing database and can't change the schema at all (be it adding a column or otherwise) then you kind of need to just use the mapping flexibility to map your changing object model with the RDB as you go along. Not much choice in that case.
 
Samanthi perera
Ranch Hand
Posts: 510
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can't we use xml file to save data?
 
Mike Keith
author
Ranch Hand
Posts: 304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, yes, you *could* store some of your data in an XML file, but I wouldn't recommend you split your entity data across an RDB and an XML file. Although something like EclipseLink can support mapping a single class to the database and to XML, I do not believe that Hibernate supports this, and I don't think it would be wise anyway.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The other scenario is if say you add an attribute to your class and don't have a column, nor want one, then you just annotation that attribute with @Transient.

Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic