• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Validation for Entity fields

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
    Greetings to all!

    I need to constrain the values of Entity-field by a set of defined int values. For example: 3,8, 11, 20...
    Existing bean validation annotations (@Range, @Min, @Max...) inappropriate for this purpose

    I tried to create own validation-class:



  Entity:


    And where its better to store check (etalon) values for this entity?
    I cant create a List with it in entity-class.

    Other approach: to create class for storing. For example:


   Its working. But... the whole class for some int storing!  It does not even an Enum!
   From other side, my application contains of 14 such entities. And with store-int classes a number of classes will achieve 28.
   I don't think, its a good practice.
   May be, other approaches?

   

 
Saloon Keeper
Posts: 21311
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suppose there are a couple of things you could do. For one thing, you could keep your valid values as a java resource file and load it via the properties functions.

When I do stuff like this, however, I usually do it in other ways. For example, if certain values are absolutely forbidden to ever get into the database, I'd simply define them as constraints in the database itself. That's not done lightly, since it requires the DBA to do any maintenance on what is and isn't a valid value. And the overhead is considerable, since validation isn't done until you actually commit the data. But it does provide the ultimate protection.

More often, I don't do this sort of stuff in the ORM code at all, since it's actually often simply business logic. So I'd simply check the values being set in the persistence methods and throw an exception or return an error. You don't get cross-application value protection this way, but it's easier to adapt to changes in business needs.

Another, related trick is to keep the value values in a separate database table (lookup table). Since discontinuous values often have special meanings, this can be especially helpful. For example, if the code is an office location with 1 being Kolkata, 2 being Mumbai, 4 being Birmingham, and so forth, not only can you gain flexibility by making the value a foreign key (and thus checked by foreign key constraints), but also you have helpful human-readable information attached.
 
Andrey Dmitriev
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
   Tim Holloway, thanks for detailed and meaningful answer!
   I considered the last approach from among you suggested.

   With using ORM that means, that I need to create one more entity for a separate table.

   
 
Tim Holloway
Saloon Keeper
Posts: 21311
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Andrey Dmitriev wrote:    Tim Holloway, thanks for detailed and meaningful answer!
   I considered the last approach from among you suggested.

   With using ORM that means, that I need to create one more entity for a separate table.

   



Correct. And you'd have a many-to-one correspondence from the primary table. Standard stuff, actually, and quite efficient for small tables that can be locally cached.

I used to work in a shop where we had naming conventions for tables. I've forgotten them all now, but you could, for example, prefix the lookup table names with "LUT_".

A big advantage of that is that when creating a database from scratch where certain tables are (mostly) constant, you can tell by their names what stuff you'll want to keep in your database scripts. That is, you'd have your CREATE for database and tables, your key definitions (best applied AFTER initial population!) and your INSERTs for your Lookup Tables. Too often I've seen databases that grew organically and there's not way to re-create them from scratch in case of backups with no data available or if, for example, you want to spin off a test copy of a database or clone the schema for a different user.
 
Andrey Dmitriev
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
  Thanks a lot!
  I'll try different ways
 
This tiny ad is wafer thin:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!