LogicalToDisplay Method
Hi, I am trying to understand the transformational methods.
- LogicalToDisplay()
- LogicalToOdbc()
- OdbcToLogical()
- DisplayToDisplay()
I have created a small class with the only property of List as %List, see below.
{
Property List As %List;
}
Then I entered the following commands in the Terminal
Set Oref=##class(LastName.Demo2).%New()
FOR I=1:1:5 S $LI(List,I)="Value="_I
Set Oref.List=List
WRITE Oref.ListLogicalToDisplay(Oref.List)
^
<METHOD DOES NOT EXIST> *ListLogicalToDisplay,LastName.Demo2
zw Oref
Oref=<OBJECT REFERENCE>[2@LastName.Demo2]
+----------------- general information ---------------
| oref value: 2
| class name: LastName.Demo2
| reference count: 2
+----------------- attribute values ------------------
| %Concurrency = 1 <Set>
| List = $lb("Value=1","Value=2","Value=3","Value=4","Value=5")
+-----------------------------------------------------
So, what am I doing wrong here, or what do I not understand?
Mike,
You are formally correct but data type %List just has no method LogicalToDisplay !
but:
- LogicalToOdbc
- LogicalToXSD
and reverse
it seems the implementer expected us to use $ListToString(...) and $ListFromString()
so far for consistency in object model support
Hi Mike,
%List is not supposed to be used that way. It doesn't have a projection to SQL, so you can't create a property on a persistent class with it and expect it to work as a %String or %Integer property will. You could have it there as a private property for some other purpose of your class but not to be used as any other property as you expect.
I think %List was created to be used on the definition of method parameters and return types of such methods to represent a $List parameter. Then one would know that such datatype must be used and this would also be used when projecting those methods to Java, .NET, etc. for the same reason (there is a Java/.NET/etc. $List like datatype for every language binding we support).
If you need to represent names in a format such as "Surname,Name", try using %String or creating another datatype that inherits from %String and validates that the string is in such format by implementing the IsValid() method of your datatype.
Also, don't try to use LogicalTo*, ODBCTo* or DisplayTo* methods directly. Those are called by the SQL and Object engine accordingly. For instance ODBCToLogical is called when storing data from ODBC/JDBC connections. You shouldn't have to call these methods.
Kind regards,
AS
Amir,
I don't agree with you on %List
http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...
There's no annotation to be reserved or not to use it
Hi Robert,
You are right. Now I see there are methods on the datatype for LogicalToODBC and ODBCToLogical.
But I insist that the methods LogicalTo*, ODBCTo* and DisplayTo* should not be called directly. Although they will work, the correct way of dealing with data type conversions are using normal functions such as $ZDateH() with the proper formatting code.
If one wants to store names in a format where the surname should be separated from the name by a comma, I would instead simply use %String for that or subclass it to create a new datatype that will make sure there is a comma in there (although I think this is too much).
Kind regards,
AS
You are welcome.
When I loaded the class first I was surprised too just to see 4 methods.