Write a data type table between ledgers

[flowersinthesand]

See https://github.com/lecle/aloxide/issues/2#issuecomment-652303091 for the context.

[quocle108]

Table data-types

EOS

Number:

• int8_t
• uint8_t
• uint16_t
• int16_t
• uint32_t
• int32_t
• uint64_t
• int64_t
• uint64_t
• int64_t
• uint128_t
• int128_t
• uint256_t
• int256_t
• double
• long double

String:

• string (no limit)
• char (1 bytes)

Array:

• vector
• map

(In the future, EOSIO.CDT may support other array types)

Other types:

• time_point
• time_point_sec
• name
• bool
• pair
• public_key
• signature
• symbol
• symbol_code
• asset … —> User can define-key type + key-type from library




ICON

A key can be numbers or characters, and value_type can be int, str, bytes, and Address.

Number

• int (no limit to how long an integer value can be.)

String


• str (no limit)
• Address

Array:

• bytes

Other types:

• No

Table Index-key:

EOS:

EOSIO table requires exactly a uint64_t primary key.

EOSIO table table also supports up to 16 secondary indices The type of the secondary indices could be any of:

• uint64_t
• uint128_t
• double
• long double
• eosio::checksum256



ICON 



ICON Table only have one index for table and A key can be numbers or characters

[flowersinthesand]

If we would abstract EOS and ICON, would it be like the following? How do you think about that?

Data type	EOS	ICON
string	string	str
number	double	int?
Array	vector	bytes
IndexKey	uint64_t	string

And ICON doesn't support floating number type and map type?

[quocle108]

I don't think that's a good idea to abstract data type. Because each language has it's strength. Not only data type. it's related to the way to read/process the data.

For example:

• In EOS, each table can be including many fields and it allows us to index each field. So we can store as a row data, and it can easy to query back by primary/ secondary indies.

• In ICON, provides an ordered mapping from string keys to string values. Python works well with JSON data. SO we should consider storing all data in ICON as a string (Under JSON format).

[flowersinthesand]

@quocle108 I agree with your point but it's one of typical disadvantages of abstraction. Those who want to make the best use of blockchain would be eager to invest their time in learning the blockchain they chose, rather than using Aloxide.

@manh-vv According to your work a number type on the abstraction seems to be uint_64. Right? Why don't you call it just a number?

[flowersinthesand]

@quocle108 Though we may want to have exceptions or workarounds later to allow a specific feature of a specific blockchain e.g. EOS or specific categories of blockchains e.g. DPoS.

[manh-vv]

According to your work a number type on the abstraction seems to be uint_64. Right? Why don't you call it just a number?

I aim to support uint_8, uint_32 too. This allows the developer to dig in and optimize their data cost while number only be transformed to unit_64 by default. Anyways, the implementation is not official yet. We can still continue to discuss this.

[quocle108]

I aim to support uint_8, uint_32 too. This allows the developer to dig in and optimize their data cost while number only be transformed to unit_64 by default. Anyways, the implementation is not official yet. We can still continue to discuss this.

There are many type of integer in C++: uint_8, 16, 32, 64, 128 and int8,int16 .... . I agreed with @dongwakim only support double type for number. SO very easy for developers who are familiar with js. They only know string or number. (FYI, The number in js equal double type in C++)

For Array, I think we support something like Array in js. it could be a map in C++, and dict in python.

For other data types, I agree with dongwakim.

Data type	EOS	ICON
string	string	str
number	double	int
Array	map	dict
IndexKey	uint64_t	string

[danielvo11]

Should aloxide to support the following types:

Data type	EOS	ICON
boolean	bool	bool
number	double	int
address	name	Address

These types is commonly use in many case I think. The type number currently map with uint64_t in eos, it just can store integer value, sometime user need to store double value, for example vote point in D.vote. As I searched, there are no double type in ICON, so we can temporary use int instead.