disallow multiple 'sid's

antho1404 commented 5 years ago

If I deploy 2 services that have the same sid but generate different hashes (different versions), this generate 2 different sid with the same name, this should not be possible

We should only have access to one sid and not multiple

Step to reproduce:

Checkout dev branch
delete all services just to have a clean database: ./dev-cli service delete --all
download tar version of a service: ./dev-cli service deploy https://github.com/mesg-foundation/service-ethereum/archive/master.tar.gz (one sid and one hash)
download git version (different hash): ./dev-cli service deploy https://github.com/mesg-foundation/service-ethereum
List services: ./dev-cli service list

This should generate only one line but it generates two lines with the same sid

03d8dd8ed484c6605e8e0b1806dba9dcc13f450494d1edff5789f355de4e2df4    com.mesg.ethereum    Ethereum    stopped
10cba92f00b8b1821bcda583e0ac0e90b48a4243f7b0bc04c45ee17b3cbf4e6b    com.mesg.ethereum    Ethereum    stopped

antho1404 commented 5 years ago

Probably related to the service db, the service db should have a real has many relation.

sid => [hash1, hash2, ...]
hash1 => service_definition
hash2 => service_definition

for now we have

sid => hash1
hash1 => service_definition
hash2 => service_definition

We are loosing some informations and also the All function is getting the hash first instead of the sid.

We should have

res = []
for all sid
  hashes = get_hashes_of_sid(sid)
  hash = get_last_hash(hashes)
  def = get_definition(hash)
  append(res, def)
return res

Now we have

res = []
for all hash
  def = get_definition(hash)
  append(res, def)
return res

NicolasMahe commented 5 years ago

If I deploy 2 services that have the same sid but generate different hashes (different versions), this generate 2 different sid with the same name, this should not be possible

It's a feature actually. The sid you get from the command service list are not the index in the database but simply the Sid parameter in the Service struct.

for now we have

sid => hash1
hash1 => service_definition
hash2 => service_definition

This is not true. The current implementation always replace the link from sid to hash with the latest deploy service:

https://github.com/mesg-foundation/core/blob/6ac229de95a1231993030ea8fbf7946ace74f2e3/database/service_db.go#L194-L198

So, it's actually:

sid => hash2
hash1 => service_definition
hash2 => service_definition

Otherwise, yes we should implement the one to many relation between sid and hashes (in a separated db i would recommend) in a "add on top" way, so the latest added hash is the first element of the one to many relation (will be easier I think to get the latest).

antho1404 commented 5 years ago

It's a feature actually

That's a really confusing feature... Sid is the entry point to the last version of the service so it's quite confusing when you have multiple entry point

NicolasMahe commented 5 years ago

@antho1404 i think we can close because https://github.com/mesg-foundation/core/pull/839 has been merged

mesg-foundation / engine

disallow multiple 'sid's #783