To achieve best performance and validation convenience, which of these annotations are needed for a String field?
database: MySQL
A field to store district name
#Column(length=50) // javax.persistence.Column
Is this going to be converted to varchar(50)? Or I need this one specifically:
#Column(columnDefinition='varchar(50)')
And another two annotations
#MaxLength(50) // play.data.validation.Constraints.MaxLength
#Length(max=50) // com.avaje.ebean.validation.Length, is this one useful or not required anyway?
public String districtName;
I think I need #Column(length=50) for definition and #MaxLength(50) for validation at same time? Or one of these two will imply the other one automatically?
Thanks.
As far as I know, when we mark String variable with these annotation:
#javax.persistence.Column(length=50)
#javax.persistence.Column(columnDefinition='varchar(50)'). Note: I am use postgreSQL, and this will create column definition with character varying data type
#com.avaje.ebean.validation.Length(50)
the three annotations above has the same purpose. Those will create column definition with character varying data type and length of 50 characters on database.
Without the #Constraint.MaxLength(50), you will get exception like below when you entered input value whose length greater than 50:
Execution Exception
[ValidationException: validation failed for: models.TheModel]
I think, there should be a way to handle above exception, but honestly I don't know how to do that until now.
Advice
My advice for you is to choose one out of the 3 annotations above (It is your preference) with the use of anotation #Constraint.MaxLength(50). For me, it is the easiest and the simplest way, and you can easily make the form using play framework scala-template-helper.
Related
Using EFCore 6 ...
I have a variety of values in a column I want to use as the discriminator column.
There are certain values (SERVER_STS) I am mapping to entity classes
modelBuilder.Entity<QueueEntry>()
.HasDiscriminator<string>("TaskType")
.HasValue<StatusEntry>(Constants.TaskServerStatus)
.IsComplete(false);
I, ideally would want to map all the other values to generate a single entity class, QueueEntry. So something like
modelBuilder.Entity<QueueEntry>()
.HasDiscriminator<string>("TaskType")
.HasValue<StatusEntry>(Constants.TaskServerStatus)
.HasOtherValue<QueueEntry>();
I thought the IsComplete might help, but I'm only getting back the StatusEntry rows.
I can't see a way of doing this. I see there is an Expression overload for the HasDiscriminator method, but can't quite get my head around whether this might give me what I need.
So is this possible or will I need to segregate the entities at a higher level?
I am reading a fixed-width file in mapping Data Flow and loading it to the table. I want to validate the fields, datatype, lengths of the field that I am extracting in the Derived column using substring.
How to Achieve this in ADF
Use a Conditional Split and add a condition for each property of the field that you wish to test for. For data type checking, we literally just landed new isInteger(), isString() ... functions today. The docs are still in the printing press, but you'll find them in the expression builder. For length use length().
Can someone advise me on the SQL data type that should be used for a DICOM UID, 1.2.840.113986.3.2702661254.20150220.144310.372.4424 as a sample. I would like to use it as a primary key as well.
There are two options available here- either use a less-than-ideal data type which already exists, of which "text" is almost certainly the best option, or implement a custom data type for this particular type of data.
While the best built-in option is "text", looking at the example provided, you would likely get significant performance and space benefits from using a custom data type, though it would require writing code to implement it.
A final option to consider is to use a surrogate key for that data. To do this, you would build a table which contains a "bigserial" column and then a "text" column. The "text" column would hold the long form of the value as you have it shown above and the "bigserial" column would provide an integer (64bit with bigserial, 32 bit if you use "serial" instead) which you would then use in all of your tables, instead of the long form.
I have this simple flow in Talend DI 6 (simplified for posting on SO):
The last step crashes with a NullPointerException, because missing XML attributes are returned as null.
Is there a way to get empty string values instead of nulls?
For now I'm using a tReplace step to remove nulls as a work-around, but it's tedious and adds to the cost of maintenance by creating one more place where the list of attributes needs to be maintained.
In Talend DI 5.6.2 it is possible to add default data values to the schema. The column in the schema is called "Default". If you expect strings, you can set an empty string, which is set if the column value is null:
Talend schema view with Default column
Works also for other data types. Talend DI 6 should still be able to do this, although the field might be renamed.
This is probably a super simple question, but I'm struggling to come up with the right keywords to find it on Google.
I have a Postgres table that has among its contents a column of type text named content_type. That stores what type of entry is stored in that row.
There are only about 5 different types, and I decided I want to change one of them to display as something else in my application (I had been directly displaying these).
It struck me that it's funny that my view is being dictated by my database model, and I decided I would convert the types being stored in my database as strings into integers, and enumerate the possible types in my application with constants that convert them into their display names. That way, if I ever got the urge to change any category names again, I could just change it with one alteration of a constant. I also have the hunch that storing integers might be somewhat more efficient than storing text in the database.
First, a quick threshold question of, is this a good idea? Any feedback or anything I missed?
Second, and my main question, what's the Postgres command I could enter to make an alteration like this? I'm thinking I could start by renaming the old content_type column to old_content_type and then creating a new integer column content_type. However, what command would look at a row's old_content_type and fill in the new content_type column based off of that?
If you're finding that you need to change the display values, then yes, it's probably a good idea not to store them in a database. Integers are also more efficient to store and search, but I really wouldn't worry about it unless you've got millions of rows.
You just need to run an update to populate your new column:
update table_name set content_type = (case when old_content_type = 'a' then 1
when old_content_type = 'b' then 2 else 3 end);
If you're on Postgres 8.4 then using an enum type instead of a plain integer might be a good idea.
Ideally you'd have these fields referring to a table containing the definitions of type. This should be via a foreign key constraint. This way you know that your database is clean and has no invalid values (i.e. referential integrity).
There are many ways to handle this:
Having a table for each field that can contain a number of values (i.e. like an enum) is the most obvious - but it breaks down when you have a table that requires many attributes.
You can use the Entity-attribute-value model, but beware that this is too easy to abuse and cause problems when things grow.
You can use, or refer to my implementation solution PET (Parameter Enumeration Tables). This is a half way house between between 1 & 2.