Drop the "create" reference from the `get_or_create()` function name

[IaroslavMazur]

As discussed here:

"Yes agree that the function name is confusing. What the call does is that it adds address into the account storage (address storage). The create means - generate random account id, if for that account id no address is stored in storage, adds it, if there already is address for that account id, just returns it. The creation here is just empty account creation which is added into the address storage.

But completely agree this is confusing and we need to get rid of it."

Originally posted by @lukacan in #380 (reply in thread)

[lukacan]

Hello, thanks for the issue. This is just a prototype right now, but would you something like this find easier to use ? example.

The update simplifies usage of the account storage, the storage would be rename to address storage as it only stores addresses. The mint, token account etc. creation would be separated and added to the Trident struct.

• There would be just two methods, insert, which adds a new random address, or PDA if seeds are specified and get whcih returns random address from the address storage.
  • ex. you run insert in a for loop 10 times -> 10 random addresses are inserted into storage -> get will obtain random one -> address can be used in instruction, you can airdrop to it, initialize mint on it etc.

[IaroslavMazur]

thanks for the issue

Just doing my part to enhance the DX on Solana 🫡

Thanks for listening to feedback!

the storage would be rename to address storage as it only stores addresses

Agreed!

The mint, token account etc. creation would be separated and added to the Trident struct

Cool!

insert, which adds a new random address

2 ideas/concerns:

1. Wouldn't it be better to keep the multiple functions that add addresses to the storage (i.e. generic - and the separate ones for mints and ATAs), in order not to complicate the process of adding a mint/ata address? The functions could be named insert() (the equivalent of the current get_or_create()), insert_random() (when you need just a plain "EOA" account), insert_mint() & insert_ata(), respectively
2. Currently, Trident lets you specify the account_id of the created account. This will be kept untouched, right?

get whcih returns random address from the address storage

As long as there's, also, an option to return a specific address (based on its account_id), I'm fine with this!

address can be used in instruction, you can airdrop to it, initialize mint on it etc.

I believe that the current approach of "intentful account creation/generation" (where the type/layout of the account data is specified upfront via the mint/ata keywords) is better than the proposed one (which'd force you to do this in 2 steps: first, generating the address and, then, initializing it with custom data).

[lukacan]

The account_id will be removed. To put things into perspective. The (account/address) storage is important in order to also fuzz accounts.

Ex: instruction contains 4 accounts on input, we want to be able to "send sometimes correct and sometimes incorrect address" to see if validations are in place. This was ensured by account_id, if we select account_id = (0..5), one account_id will be correct, the remaining 4 likely not, I think you understand this part.

The new mechanism would be to remove the account_id completely, it confuses users.
Instead, each account would/could still have its own storage, but insert() would add a random address to storage and return it for you to use in instruction (ex, initialize instruction requires some admin/author whatever account).
Later, in order to just obtain an address without adding, the get() function would be used (function selects a random address from storage, ex, if an initialization instruction was executed, now some update instruction requires the same admin as initialization).

I think this approach is correct, because:

• It does not use any account ids, it just adds and selects from storage
• It still allows you to use variations of accounts as you can, for example, insert 10 random addresses to the storage (calling insert() in a for loop 10 times -> filling the storage with random addresses).

Regarding function names, good idea, insert(address), insert_random() and get() are imo best fit right now. insert_mint would be not useful as mint creation would be split from storage, so, 1. insert address, 2. call trident client method to initialize mint on that address 3. use address in instruction (Mint is already initialized at this point). The init_ata() is imo also not so good as ata is just a special case of address, so this will be left to the user to derive the address before and then use insert(address).

As long as there's also an option to return a specific address (based on its account_id), I'm fine with this!
This will still be possible as you can have just one address in storage, same as account_id = (0..1)

[IaroslavMazur]

Sorry for the delay in getting back to this!

@lukacan, I'm gonna trust your judgement re the discussed subjects - and come back with any findings after the next version is released!