hello is there a module that allows you to archive data from several modules at the same time (sale, purchase, invoice...) on Odoo 10 CE?
a bit like the record_archiver does in ODOO versions 7,9 and 11.
https://odoo-community.org/shop/product/records-archiver-4101?version=9&page=4
If you want to use this module which is in 9 & 11 version then simply go for migration of this module.(into V10)
So you can brush up your skills with migration also.
Related
I've been working with Oracle PL/SQL and forms ¿for the last 20 years.
Like 8 years ago oracle people started to say their route map was that every new development should be done in Java with ADF and not in forms.
5 years ago we had to start a new project so we did it using that technology, because we had the feeling that sooner or later Oracle was going to stop suporting and publishing new versions of forms and reports.
The project was successful, but mantinance, deployment and configuring the developer's PC's is a lot hard and painful.
Starting with the fact that we have to deploy all the application every time we do an small change in any page, comparing with the fact that in forms we just have to deploy the altered form's FMX
And that is not the most unconfortable part, some times we deploy the applications EAR and we do not know why some classes are missing, so we have to compile everything again and deploy again.
In the last month we had to change our old Win 7 PC's for new ones, but I do not know why when I run the ant XML that should generate the EAR it does not find oracle.jbo.server package
Is this developing environmet always so hard and buggy ???
Although I understand this thread below is a bit old... but still a good source to refer it.
What is Oracle ADF?
We are new spring-roo but very familiar with RAD on PHP using Yii & Active Record.
I was able to run roo> database reverse engineer --schema to create models off an Oracle database for a proof of concept I am working on. The command line freezes since the 3rd attempt to update the schema. The difference between the first two attempts and the 3rd one is that we used the --includeTables option without knowing that it would overwrite the entire dbre.xml (instead of doing an incremental change). We have cleaned the cache and even reinstalled roo but the issue persists. Even creating a new project did not help. I can see the following in spring-roo logs:
// Spring Roo 1.3.2.RELEASE [rev 8387857] log opened at 2016-04-13 19:39:41
database properties list
// [failed] database reverse engineer --schema pfadmin --package ~.domain
Any idea or help is welcomed.
Found the solution after half a day of investigation. Spring roo performs an analyze table while reverse engineering the models. If your database is very large, then the compute statistics will take a long long long time :D
My advise export the database as DDL only not data, create an empty development database and run spring roo against to get your models.
I have a DotNetNuke 7 website that I have developed and an older version that was made in 4.9. I have to find a way to migrate the users into the new database so that the users of the website do not have to change their passwords or be inconvenienced in any fashion.
I have attempted to use plugins for this, but I cannot find one that exports 4.9 (seeing as 4.9 is so old) and another to import that file into 7.
If I try to go the manual migration route, what records would I need to pull over? I have noticed there are various user related tables. Are all of these mandatory for migrating users?
Thank you for your time. I'm just trying to understand how to go about the migration and would greatly appreciate some guidance.
You can do this via the database but you have a number of tables that you have to move across and you have Integer Based ID's that you have to worry about. Some of the tables to be aware of are aspnet_membership, aspnet_users, Users, UserProfile, ProfilePropertyDefinition, UserRoles, UserPortals and then there can be more as well.
DataSprings has a module called Interactive User Import which can also do an export. It works great and you can get a version that works that far back.
The other thing that you have to worry about if going truly the DB route is that passwords are encrypted, as such, if you move the passwords manually you have to keep the same encryption key.
Last week i read about liquibase quick start and all the related tutorials but i feel like i don't get the whole drift about using it for consecutive change in the database and i have some questions still opened.
i'm developing an application in netbeans using maven with 3 modules: dbunit module, service module and the webapp module.As you might have guessed dbunit does the database stuffs, the service is on top of it and the webapp uses the services.so the parent pom has the declaration of all groupids, artifactids and versions for all jars and plugins.
I manage to generate the changelog file from command line since the db is already existing and supposing i set up everything correctly using liquibase maven plugin :
question 1 : What will the liquibase goal be since right now i'm doing any database change right now?
Question 2 : If i want to add for example a new table to the database, will i add the this new changeSet to the same changelog file or i have to create a new changelog.xml file?
Question 3 : I believe when the dbunit runs it will run the changeset but is that necessary to add the plugin to th webapp module too (maybe to run the liquibase goal before deployment with cargo plugin) or the dbunit will take care of that?
Question 4 : What exactly subversion helps with keep the states of the changelog (assuming there is only one changelog refere to question 2)
thanks for reading this and for you help.
See http://www.liquibase.org/documentation/maven
so you should bind your liquibase execution to a phase like
<phase>process-resources</phase>
But i use a spring executor, too. So everytime my app starts up, it starts a liquibase executor to execute missing changelogs in the database. It is nice, because when you are ready with your work and your tests, liquibase has updated your dev database but not your production database. But when you install your war and start your webapp, liquibase handles it automatically to bring your database to current state. So you don't have to remember doing some extra stuff before deploying your new version.
Keep your changelog.xml with includes to changelog files like this
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">
when you want a new table, add a changelog-0002.xml file and reference it in your master changelog.xml
see answer 1. I would put in your webapp module too.
You should have many changelog files. so this question is not applicable.
Since I've not done this before I am not sure if the way I am planning to do this is okay or is there a better way. Like using Windows Installer or Install Shield or Windows Installer XML (WiX) toolset. Any help would be great, as I have no clue.
We have a product and we ship new version every few months. So far we've only been rolling out complete versions i.e. Either Version 1.0, or Version 1.5, but no upgrade from 1.0 to 1.2 to 1.3 to .... you get the picture, right! So any customer that get version 1.0 cannot upgrade to version 1.2 or 1.3 or even the latest. They'll have to uninstall old version and install the latest version. This is not right, but thats what we could do until now. But we'd like to change it.
My plan is to have a install file with (Sql Scripts) for each upgrade path. Check the table in database that stores the version info and depending on it run different script to upgrade database.
My concern is that this method may not be scalable, once we have more than 5 or 6 different versions.
If you could point to any articles or books on this topic, that would help a lot too.
Also, could we use Windows Installer or Install Shield for this?
thanks,
_UB
We've been using DBGhost for a year or so now to keep our database under source control along with our codebase, and it makes this kind of thing dead easy. It's not just well thought through, but they've been using it to roll out their own code for years, so it's dead solid.
Your problem is a pretty common one, and I've had to deal with this kind of problem at my last job. There is another tool aside from the RedGate tool that may help you do what you need to do. It's a tool called DB Ghost. They explicitly address the versioning problem, and have a packager as well. I would suggest doing a trial of the DB Ghost product because they have some interesting claims concerning multiple version upgrades. This was taken from their FAQ (http://www.innovartis.co.uk/faqs/faqs.aspx):
Q: Our problem is going to be managing
data structure changes during
upgrades. Our product line is
Shrink-Wrapped, or downloadable from
the website. So when a user downloads
an upgrade, they can be upgrading from
a very recent version, with few
database structure changes, or the
upgrade may be from a very old version
with a multitude of structural
changes. One upgrade needs to manage
it all. The user would be offsite, so
we can't hold their hand. We have
users in Greece, Australia, Malaysia,
Norway, etc. How would DB Ghost, if at
all, handle updates in remote
locations?
A: The DB Ghost Packager Plus product was
design to specifically address this
issue as it can dynamically handle the
required updates to a target database
seamlessly.
I'm just mentioning this because our company is trying to do something similar and I was doing research on this tool.
Thanks,
Eric
Do you insist on doing it yourself, or could you see yourself committing and investing in a tool?
I really like the idea of Red-Gate's SQL Packager, which will "diff" your two database versions, and then create a SQL script, a C# project, or a stand-alone executable to upgrade from version 1 to version 2.
Not 100% how you'd be able to upgrade from 1.0, 1.1, 1.2, 1.3 all to 2.0 - check out their website and see if they offer something for that scenario!
Otherwise, I guess it'll get quite thorny and messy......
Marc
In the Rails world they are using a tool/method called Migrations.
Basically is boils down to creating a small sql script to upgrade and downgrade each little change to the database.
When you are testing the application you migrate your database to the version you want and on deployment the application can check what version it needs and migrate to that version.
There are free migration toolkits for most popular languages, they might be part of some MVC framework though.
A nice side effect of migrations is that you have database source code that is easily stored in you source control repository.