I am using https://yos.io/2018/10/28/upgrading-solidity-smart-contracts/ link for upgrading smart contracts which have listed Smart Contract Upgrade Mechanisms.
Is it possible to make change itself in registry smart contract and upgrade it.
The purpose of a registry contract is to store a mutable reference to the latest versions of your smart contract modules. It serves as a first point of access for your decentralized application.
So there are two options if you want to upgrade a registry contract:
have another (fixed) registry contract pointing to your (dynamic) registry contract
update the reference to your registry contract in all places that use it (i.e. the frontend application)
I hope this answers your question.
Related
I need to know which instuctions list is used for a transaction in order to use it in my application.
For example:
There is an unknown NFT marketplace, I can buy NFT through the "Buy" button in the browser.
I want to buy these nft programmatically, not through the browser.
To do this, I need to know all the instructions and transactions.
And in general, can I buy NFTs if the marketplace does not use CandyMachine, MagicEden, etc.?
Each marketplace/platform has a different way of managing transactions.
If you are interested in how transactions are put together and want to start building an understanding of the ecosystem, you have two options:
pick an open source repo (on Metaplex on you have auction house / storefront / fixed price listing / candy machine at least ). Some of these will have template UIs as well that you can customise to suit your needs. They come with several examples of transactions so that you can learn to build them from ground up.
Pick a proprietary framework (like Magic Eden), and interact with them via their API. You will not be building the transactions yourself in this case. In the case of Magic Eden, they build the transaction instructions serverside and serve them over their instructions API. You will not know (nor would you necessarily need to know) how the transactions are put together, as they've handled the abstractions for you.
Some examples of different NFT frameworks in the solana space:
Metaplex Auction Manager (open source) + Storefront UI. Useful for learning about how transactions are created, but probably unwise to start building a long-term solution on top this. Also Storefront UI is in places quite complex but as long as you just focus on the transactions and how they are generated, it's a useful pedagogical tool.
Metaplex Auction House (open source) is intended as a replacement for Auction Manager framework. Like the Auction Manager, Auction House is open source and there are multiple examples of how to use it in metaplex repos.
Metaplex Fixed Price (open source) is another listing framework with its own set of contracts. Again repos are available on metaplex github.
Magic Eden (proprietary) expose their transactions via an API, which gives you serialized transaction. You can use the transactions generated by their API in your application, but because ME is not open source, you will not be able to generate the transactions from scratch.
The above are just examples. However, the one thing they all share is that they use Metaplex standard for expressing their mint metadata. The way ownership is expressed via TokenAccounts is also standard across all, which means that as long as you hold NFts in your wallet, you will be able to list them in any of the above.
In addition to the above, Metaplex discord is also a useful source of information with a friendly community, but please check the growing SO knowledge base first.
If I've deployed a smart contract on NEAR, how do I upgrade it to a new version? How can I tell if an existing smart contract can still be upgraded or has been frozen?
In addition to the answer Erik already provided, I want to mention that even when there is no full-access keys on the account, the contract code can be re-deployed by the contract implementation itself (obviously, it should have a built-in support for that). You may also want to combine that with DAO to make the upgrade process backed by a voting process.
Upgrading is done with access keys. If you want to be upgrading, you keep a full access key to the account, which allows you to deploy or delete/recreate/deploy.
Anyone can view the upgradeability of a contract (eg whether it can still be changed by the original owner) by viewing its keys to make sure that all full access keys have been removed using:
NEAR_ENV=mainnet near keys contract_name.near
First of all, I have pretty much no experience with developing Exchange Web Services-based applications.
I am developing an application that uses EWS Managed API to connect to an Exchange server. I need to support multiple Exchange versions, as I can't know in advance what version the server I'll be connecting to is running.
I was reading this article: https://msdn.microsoft.com/en-us/library/office/dd633705(v=exchg.80).aspx, and in the Unsuccessful Versioning part, it's written:
The EWS Managed API will throw an exception if the example is run because the IsAssociated property on the EmailMessage object is not available in Exchange 2007 SP1.
My question is: is there a list of which properties are available (or unavailable) in each Exchange version?
You have to keep in mind that the EWS ExchangeVersion (schema version) is not the same as the Service Version, on which Exchange is running.
Microsoft says:
[...]applications designed against earlier versions of EWS will work, in most cases, with later versions of EWS, and applications that target later versions of EWS will work if the same functionality was included in an earlier version.
You can find further information about schema versioning and your requested feature set per schema version here: https://msdn.microsoft.com/en-us/library/office/dn741586(v=exchg.150).aspx
There is no list of properties that i know off probably the closest would be if you look at the EWS Managed API source https://github.com/OfficeDev/ews-managed-api/tree/154dbc66ac018d861c73ce489839cd9f58a1b0cd/ComplexProperties .
There are strongly typed properties which Microsoft have made available on the EWS objects and you can also access the underlying extended properties these strongly type properties refer to (or that no strongly type property exists). Just because a property isn't strongly typed in a certain version of EWS doesn't mean its not accessible its just you need to use another method more on that https://msdn.microsoft.com/en-us/library/office/dn467898(v=exchg.150).aspx
There is a list of which EWS operations are available in which versions https://msdn.microsoft.com/en-us/library/office/bb409286(v=exchg.150).aspx which is generally the more important. (Eg FAI Folder Associated Item traversals where first introduced in 2010 hence why isAvailble isn't in 2007).
I currently developing a multi tenant saas application using asp web api. The api will be published and consumed by 3rd party application. My question is regarding versioning. I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api. I also have to update the old api to adapt to database change. That seems like a lot of work. How do big companies solve this problem?
There is no easy way around this; you will have to do the work to support old versions as long as your customers are using them.
Adopting a RESTful approach in the first place, and avoiding 'fat controllers' may help reduce the pain but beyond that every old API call will need to call into your new service layer and will need to return the results in the format your clients expect.
I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api.
No one, absolutely no one has researched, built, versioned and maintained APIs more than NetFlix - not externally but internally. They used explicit versioning (e.g. URL) in their APIs and maintained multiple versions of the same API and got their clients move along by providing incentives (new features). This is also something that can be built into your SLA, e.g. you guarantee support of particular version only for 12 months.
This is a very controversial topic and you will hear people suggesting implicit versioning (e.g. by media type etc). Feel free to listen to those but pragmatism favours explicit and purism favours implicit.
I'm developing a Multi-tenant solution and I want to use the latest ASP.NET Identity framework specifically the Entity Framework implementation.
Basically I need to allow two users to have the same username, though it must be unique within a tenant, I'd also like to make use of external sign-ins such as Twitter, Microsoft, Facebook and Google.
From what I can tell, the framework was not designed with multi-tenancy in mind, though it does seem to allow extensibility. I'd prefer to make use of as much existing components as possible, though at the moment I think I'm going to have to abandon the Entity Framework implementation, and code it all myself.
Has anyone else tried this and how much have they had to code themselves.
I've now got a working solution that I've shared in a GitHub repository:
https://github.com/JSkimming/AspNet.Identity.EntityFramework.Multitenant
The extensibility required to support multi-tenancy is not possible with the 1.0.0 release of Microsoft.AspNet.Identity.EntityFramework (at least not without a lot of custom work), but is available in the 1.1 alpha release currently available through the Nightly ASP.NET Web Stack NuGet Packages.
I've decided to release what I've produced as a NuGet package AspNet.Identity.EntityFramework.Multitenant, as stated it currently requires the Nightly ASP.NET Web Stack NuGet Packages.
I've provided two simple sites that make use the package to allow for multi-tenancy:
Vanilla Implementation which is the standard MVC5 template project that uses a string primary keys.
The changes necessary to provide multi-tenancy have been isolated to this commit.
Integer Primary Key Implementation which is making a few more customisations to use integer primary keys
The changes necessary to provide multi-tenancy have been isolated to this commit.
I plan to update the solution as the 1.1 version of ASP.NET Identity is released.
I hope others find some use in the nuget package I've released, any feedback is more than welcome and please raise any issues you find.
Update
The solution has now been updated to use the 2.0 release of Microsoft.AspNet.Identity.EntityFramework.
Yeah we explicitly left this as an extensibility scenario. You should be able to do this via overriding UserManager properties and implementing your own custom IUserStore. Although you might be able to extend the EF UserStore potentially as well and just add a tenantId to your user.