Adding custom comparator for integer sorting in Nattable - nattable

I tried sorting header layers, which is working fine for Text but not for Integers and dates - so I want to create a custom comparator for that.

First a comment on your issue. Sorting of Numbers and Dates is working pretty fine in NatTable. In fact the sorting of all Comparable data types is working fine with the DefaultComparator applied by the DefaultSortConfiguration. But to make it work correctly, you need to register the according data type converters as shown in various NatTable examples. Without the converter all data in NatTable is treated as String, which results in "incorrect" sorting.
Second to your question. You can register a custom comparator like this:
configRegistry.registerConfigAttribute(
SortConfigAttributes.SORT_COMPARATOR,
new MyCustomComparator(),
DisplayMode.NORMAL,
CUSTOM_COMPARATOR_LABEL);
So you need to register a Comparator for the configuration attribute SortConfigAttributes.SORT_COMPARATOR and an according label.
But if you do not have a matching type converter, you will need to compare Strings. So IMHO you need to register a DisplayConverter and sorting works as intended without the need for a custom comparator.

Related

How to Validate Data issue for fixed length file in Azure Data Factory

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().

Implement custom comparison in postgresql

I have some data in a postgres table with one column called version (of type varchar). I would like to use my own comparison function to to order/sort on that column, but I am not sure what is the most appropriate answer:
I have an JS implementation of the style comp(left, right) -> -1/0/1, but I don't know how I can use it in a sql order by clause (through plv8)
I could write a C extension, but I am not particularly excited about this (mostly for maintenance reason, as writing the comparison in C would not be too difficult in itself)
others ?
The type of comparisons I am interested are similar to version string ordering used in package managers.
You want:
ORDER BY mycolumn USING operator
See the docs for SELECT. It looks like you may need to define an operator for the function, and a b-tree operator class containing the operator to use it; you can't just write USING myfunc().
(No time to test this and write a demo right now).

Play!Framework 2 Java model string field length annotations

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.

IntegerColumn not available in GWT?

I am new to GWT and I am trying to make a simple table in GWT.
The table has string and integer types.
However, GWT has only TextColumns which returns only Strings.
But there is no "IntegerColumns" which returns Integers, so what's the easiest way to design it ?
Right now I convert Integers to Strings but this solution is not suitable for sorting the columns.
Why don't you use Grid? Grid is able to store objects as rows;
For example you want to have a look Grid
And maybe you'd like to see GXT samples

Casting/Converting Chars to Varchars by UDF for SSRS

The database which I report from most often is not properly typed. Almost every field, with the exception of some integers and datetimes, are CHAR fields. This can cause problems with SSRS layouts because some fields have tons of trailing spaces.
This causes layouts to be messy and such. I often rtrim these fields in my scripts to prevent this.
Is there any performance impact if I create a general UDF to automatically perform this on multiple fields in a single script?
Is one function RTRIM. CAST, Convert, etc preferable over the others?
I would not make a function to do this, just use CONVERT() on each improperly typed column in the result, something like this:
SELECT
CONVERT(int,RowInt) AS RowInt
,RTRIM(CONVERT(varchar(15),RowString)) AS RowString
,CONVERT(datetime,RowDatetime) AS RowDatetime
,CONVERT(numeric(10,4),RowNumeric) AS RowNumeric
FROM ...
this way, each column of the result set has the proper data type, and SSRS will know this and can apply formatting to them.
if this is a real chronic problem, and you find you are repeating the CONVERTs too much, you may want to just create some views that do this for you. just watch out making views of views of views.