I am load testing on Google compute engine at the moment. We're considering moving our code onto compute engine and then migrating to app engine.
I've got some questions regarding what is possible on the platform and I'd like to buy a support package. Only problem is I'm currently using a test project and not the final project which we will be using. Therefore I'd like to know the following before I sign up for support.
Can I cancel the subscription for support or change it or is it an annual contract?
If I get support on one project can I migrate this support package to another project?
Perhaps, could I cancel the support package on one project and start it up again on another?
If I cancel a support package will I be billed for the whole month?
What will happen to my 'Europe' App engine apps if my support package is canceled and moved?
Thanks so much for your help.
Silver and Gold support packages are billed monthly and can be cancelled at any time. Since the Platinum support package can only purchased directly from Google sales, I imagine some type of contract is signed. More info here: https://cloud.google.com/support/
Since the support package can be cancelled at any time, if you wish to migrate it to another project you can simply cancel it on the first one and then purchase it on the second one.
Yes, you will be billed for the whole month if you cancel your support package before the end of the month.
All apps remain functional regardless of the support package.
Our firm provide a web based product which is deployed onto multiple brands (customers) in a different data centers. Due to regulation concern we cannot multi-tenant architecture with our services.
Our code base is identical for all brands and we deploy each version to all brands in a lag of few hours up to a week (i.e we may deploy version V to brand A at 8:00AM, to brand B at 10:00AM and to brand C a week later).
We use Jira OnDemand as our task management system. The problem I'm trying to solve is that Jira supports only one release date for a version but since we release each version multiple times we should know somehow what date each version was release on (besides of course using a spreadsheet).
I appreciate any idea that can make my life easier.
Thanks,
Gil
I would start by imagining how you would do it with a spreadsheet. For the same version name V you would have a column named something like "Deployment Date and Time". I'd do the same in JIRA - create a custom Date and Time picker field and when a specific customer is updated, set the custom field to the date and time.
I'd try to create multiple versions for the different brands and have those multiple versions assigned to a single Jira item. The versions can then be released independently. So for example my version list would look like this:
Brand1-0.9
Brand1-1.0
Brand2-0.9
Brand2-1.0
Brand3-0.9
Brand3-1.0
This is a bit of effort, but I think it should solve your problem. It would also keep you flexible, different release dates for different brands are no problem this way.
I am working on a project that would greatly benefit from a column store database on the backend. I was attracted to LucidDB since the feature set seems perfect, and I cannot commit to the cost of a commercial solution like Infobright or Vertica until the project has shown value.
The problem is, I am concerned about the health of the LucidDB project. The internal wiki hasn't been updated in more than a month, and the website is full of broken links. DynamoBI dying does not help the case.
Is there anyone who knows the state of the project, and how comfortable you'd be with production code relying on this database?
LucidDB is no longer supported by DynamoBI as they are closing the shop.
http://www.nicholasgoodman.com/bt/blog/2012/10/08/dynamobi-is-dead/
Dr.Bharatheesh Jaysimha
I need the Database Schema Diagram for DotNetNuke (ERD) if someone have any idea.
I have searched on Internet but have only found this link which contains lots of documentations about DNN. I only need the ER Diagram for the DNN Database.
Thanks.
Have a look at this link RI website Its for the 5.2.2 CE later versions l would have thought have not changed that significantly. This company does release ERD's from time to time so worth checking back every so often.
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.