I have a big database of activities which in the LCI have activities from an old ecoinvent version.
Is there a fast and easy way to update all the LCIs in the database so that they use a newer version of ecoinvent?
I suppose there might be problems of activities not existing anymore/changed names, if that can be a case, how do you manage that?
I'm new to Brightway so I have no idea about how to do this ;).
Thanks a lot!
Daina
There isn't yet, but we are working on it. What we normally recommend is to have a reproducible workflow, using whatever data source you prefer. It is very helpful to be able to reproduce your projects if something happens to your computer, and in this case you could re-create your own data and link it to a newer version of whatever database. But you are right, things change from version to version, and this normally requires some metadata on how to handle these changes - hence the library under development.
Related
my PC changed but I would like to continue with SPSS test version on my new one. HOw can I deactivate the test Version on the old one? It is already deinstalled.
Thanks a lot.
Best regards
Henriette
Have you tried to simply install your test version on the new machine and to see if that works out?
According to this IBM support page,
A valid Authorized User product authorization code can be used to license up to two (2) product installations used by the same individual.
That might hold true for test versions as well, so maybe you can just reinstall it and carry on.
Otherwise, it never does any harm to write IBM support a quick e-mail describing your problem, as license transfer should be a routine situation for most software developers.
I published my app on play store and I have made an update that may cause the older one to crash due to some database structure changes that I have made and I have had a hell of hustle trying to automate DB migration upon installation. So I want the to completely auto-uninstall the old one from users phone before new one is installed during update as an easy solution. Is there a way I can include such configurations?
No, there is no way to force uninstallation before installation. But it sounds like you could just delete your DB on upgrade using SQLiteOpenHelper
If you use GreenDAO
you can use the schema version
Schema schema = new Schema(, "greendao");
when increasing the schema version GreenDAO will empty your DB and update the schema, and then you can repopulate it from the server (if applicable)
My current version of Liferay (6.2) has Alloy UI with few bugs.
Those bugs are repaired in newest version of Alloy Ui. Is it possible to use newest version of Alloy Ui instead of the old one?
Thank you.
I think it's possible, but there's a good chance, that you have to do extensive testing before doing it on your production environment and possibly some hand work also will be needed to make it work (if there is major version change, I think it won't work anyway because of the huge changes in the code base).
Good day,
I have an app with CoreData that is in the Apps Store. I have now coded some
cosmetic changes in the interface without changing anything in the CoreData model.
I did not add/delete/or change any entity or property. Now, I am ready to upload my
version 2 of the app. I am unsure whether I have to do anything so that the old data
of the users in the first version will not be deleted but will be saved in the
new app (with exactly the same CoreData model). Please be tolerant with this noob.
Great thanks,
Romeo
When someone installs a new version of an app they already have, all the app's data stays where it is-- it doesn't get deleted.
Whether this data is compatible with the new version is a different question. If you haven't made any changes to the data model, then it should be fine. But you should make sure. Testing the upgrade process is one of the most important parts of testing a new version of an app. Install the current version, generate some data, and then install your new version and make sure everything looks OK. As you describe it, there shouldn't be any problems, but you should never just trust that this is the case.
In Marcus Zarra's Core Data Migration Course on iDeveloper TV, he suggests manually locking your xcdatamodel file so that you can't accidentally make updates to it and force a migration when you didn't plan it. But I agree with Tom, test it first.
iDeveloper.TV Core Data Migration
How to manage InstallScript differential upgrades and releases.
For every version I ship, do I need to keep two releases? One for existing customers - for upgrade and one for new customers for fresh install?
Then as the product continues its life cycle, Do I need to keep all those releases so that I could create a differential upgrade?
Is that the way companies handle their releases? seems like a lot of data to keep and handle...
Are the savings (time or size) of differential upgrades worth this hassle? It sounds like it would be significantly easier to just release full the installer for both scenarios.
Whether or not you use them to create differential releases, I would suggest keeping all your previous releases around. You never know when you'll need to test the behavior of an old release, and the only real way to do that is with its original bits.
Installshield basically just moves over all of the files to the target machine's folder. Lets say you are going from version 1.0 to 3.0. Is there any real point in your case to upgrade to 2.0 before going to 3.0? Or could you really just lay down 3.0 directly? Unless you NEED an updater, then there's no point in having one.
How we handle it, is that we have two build like you said. A 'Fresh install' and 'Updater.' We need the updater though, because we have linear database migrations that need to run for each hotfix before the software can reach the newest version, so we can't just "skip" that 2.0
If we need to apply a hotfix, we create a stripped down version of the updater until the next release, where I create another Fresh install and Updater.