There still are some RPCs that use property id instead of the name for contracts

[Galuf1]

at least i know that tl_getposition uses the number of property id, for consistency most of the other RPCs that link to contracts use the name of the contract.

[patrickdugan]

Ok but should not these be interchangeable? Maybe it's easier for users to get the RPC info for all contracts and pull up the relevant property ID? Where are the strings for these contract aliases listed?

On Fri, Mar 6, 2020 at 12:39 PM Galuf1 notifications@github.com wrote:

at least i know that tl_getposition uses the number of property id, for consistency most of the other RPCs that link to contracts use the name of the contract.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BlockPo/BlockPo-to-Tradelayer/issues/197?email_source=notifications&email_token=AAS2CBPD47MNQ2527FHVT6DRGEKKDA5CNFSM4LDCVH2KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ITEPKHQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS2CBNYNA2PENAKF6DMXP3RGEKKDANCNFSM4LDCVH2A .

[Galuf1]

When we did the change it was because of series of futures, specifically when you needed to roll automatically with pegged currencies, you needed to jump internally a position in let's say LTCH20 to LTCJ20, so it was always better to search for the contract code, since for example this 2 contract could perfectly be property id 25, and 43.

But i agree, it would be easier like that, maybe when we re do the property id system that's causing this problem of not having 2 sequential contracts having sequential property ids

[Galuf1]

The strings are in the database, it's under the "name" if i remember correctly

[patrickdugan]

As long as both the unpredictably assigned property id and the more predictable codes are in the JSON of all contracts and thus wallet code etc. can loop through it and decipher, it's fine.

For Oracle contract it's not clear how the automatic code system would follow. It makes sense for Native futures because those are limited in quantity. I think Oracle admins would have to manually issue new futures periodically (presumably from the same address) and this would be something I can provide support for in .js that we open source for these enterprise users.

On Fri, Mar 6, 2020 at 2:25 PM Galuf1 notifications@github.com wrote:

The strings are in the database, it's under the "name" if i remember correctly

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BlockPo/BlockPo-to-Tradelayer/issues/197?email_source=notifications&email_token=AAS2CBP3HDCGYU7C4M627MDRGEWX5A5CNFSM4LDCVH2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOCFEBQ#issuecomment-595874310, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS2CBLUWPUS2ZISSDABZZLRGEWX5ANCNFSM4LDCVH2A .

[Galuf1]

@santos177 RPC tl_closeposition has a TODO of checking if there is matching orders to close your position https://github.com/BlockPo/BlockPo-to-Tradelayer/blob/9e543cfea202a4125488384bbfd1f42d69ab953b/src/tradelayer/rpctx.cpp#L1115

[Galuf1]

@santos177 RPC tl_getcache does't parse the address argument

[santos177]

@Galuf1 tl_getcache rpc is fixed now : #198

[santos177]

@Galuf1 RPC tl_closeposition fixed in #200

[santos177]

Closing for now. If we need contractId instead of the name , we can modify it.