Work with Database using Spock and Geb. - database

I hope someone have already faced an issue to verify that application shows correct data from database. I reviewd how groovy used SQL, but I have no idea where and how I should do that. I'm just starting to use gradle+Spock+Geb for testing application. I have a few files where I described a couple of pages from application, a couple of modules and a file with spock specification. Where and how I need to connect to Oracle DB, use SQL and compare result's data with application's ones?
P.S. I write everything in notepad++ and launch from command line writing 'gradlew firefoxTest'. Does exist any more comfortable way to work with gradle+spock+geb?
Thanks in advance.

Because there are no other answers, I wanted to provide a solution someone at my company thought of. This assumes you already have a project that uses some sort of JDBC. In our case it is JDBI.
The idea is to extend Classloader and then use that to directly access the data access object class via the JVM. That idea should work.
I have not tested it out because it doesn't completely fit our use-case. I'll admit that this does not completely apply to your use case, but technically you could just run the jar of an existing project, which can access the database.

Related

Best way to store data in wpf app

I just want to know about the best way to store simple data in wfp application. I'm using SQL CE, but sometimes I need to store simple data (for instance one string). I don't want to use for it db, and I think it's the right decision.
Could you please give me a guidance on how should I do that in best way or any useful resource?
Is there any particular features data settings storage for pattern MVVM?
Thank You.
Use Settings for exactly this scenario. It's simple, allows per user and system wide scenarios and is build into Visual Studio nicely.
Double clicking on Settings.settings in the Properties folder of your project (in Solution Explorer) brings up the editor and you can access these in code with something simple like Properties.Settings.Default.StringPropertyX.
http://msdn.microsoft.com/en-us/library/aa730869(v=vs.80).aspx
if you're going to be upgrading in the future, I suggest that you create a small abstraction layer that you can upgrade to using any DB or other source, when you need to.
Until you do the upgrade, I would suggest a simple XML file using XDocument and XElement (and the rest of that api).
The reason why I am suggesting this is because you can use Linq on them easily and this enables you to change the provider in the future without any problems.
here is the MSDN on XDocument http://msdn.microsoft.com/en-us/library/system.xml.linq.xdocument.aspx .
I hope this proves to be helpful to you ;-)
Cheers,
Max
p.s. lemme know if this is what you needed or not!
If you publish the application through ClickOnce then you can use IsolatedStorage. It is pretty easy to use, just a few lines of code. You can learn how to use it on WPF isolated storage.
If you don't publish it through ClickOnce then I would suggest you keep it simple and use static class.
you can use file system.. try to create xml file or csv file in the wpf app directory...
you can read and write to same file.. so that you can save what ever you want to that file and read from the same file..

how to transfer wordpress sql/database from local to live

So for backing up any/all my WordPress sites i use a tool called "BACKUP BUDDY" and its
a great tool and all but lately its been really buggy and today finally it went kaboom!
Usually my workflow is that i develop the site on my local machine using WAMP/MAMP.
when done and ready for testing i use the tool, move it to my personal test server to test and when happy and work is approved, i move to the real server.
Since my tool stopped working(uploads half the content) i decided to just do it manually by installing Wordpress first on the real webserver(done), Applying my theme(done),
then exporting the database sql from the local server(done), and thereafter importing it to the real server(done) and the 2xs that ive done it the site comes up blank.(outcome equals major fail!)
im assuming that something has to be changed/done in order for it to work but not sure what.
unlike a normal DB where i can talk to the info as normal, since WP is a CMS im assuming that it ties the info to the domain but again, i dont know how it 100% works...
Any ideas as to what im doing wrong? because as of now, if i cant do it like this, id have to manually create ALL the pages. Plus, if i was going to then move it from my real test server to final real destination then id have to manually redo it all again...
Thanks in advanced.
you aren't doing anything wrong. It sounds like your particular workflow could be as follows.
Upload the contents of the site via FTP
Create & Import the database via PHPMyAdmin, changing any info in wp-config.php
Define the site url, in wp-config.php [See below]
Use a tool to find & replace any hard-coded site-urls that wordpress loves to use. [See below]
Example code:
Define site urls
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
Find replace tool
Replace
http://localhost/
with
http://www.your-new-site.com/
That should be it. It's live!
You can export it using phpMyAdmin and then use bigdump to import it. download bigdump from here and make sure you read the first note about the exporting process, found here
http://www.ozerov.de/bigdump/usage/
here is a bash script you can use to automate this entire process for you: https://github.com/jplew/SyncDB

Issue With DAO 3.6 on VB6 database

I am currently in the process of trying to launch a database that has a VB6 front end connected to an access 2000 database. On certain computers we are experiencing a problem where the data being pulled from the database does not show up or does not show up correctly.
The computers that work seem to have the same dao360.dll date modified in both the system 32 and microsoftshared/dao while the one that are not working do not have the same date modified.
Is this whats causing the error? How can I correct this? Or is it something else that is happening?
There shouldn't be two copies of the DLL on the system. It sounds like a poorly designed install of some application had been previously done on these systems. There is no telling what the full extent of this has been.
Packaging as an isolated application can insulate your programs from these kinds of bad installs that create DLL Hell. Sadly MDAC/DAC and related components are very difficult to isolate.
This is another reason to have moved to ADO back in 1998, if not in the time since then. While you can't isolate the ADO-related parts of MDAC/DAC any more than you can DAO, those libraries are now shipped as part of Windows. You don't need to deploy them and they are protected from bad installers by the increasingly better system file protection mechanisms in Windows.
However providing specific assistance will probably require a more specific and detailed description of what is going on than "does not show up or show up corectly."
I'd create a minimal test case using DAO to begin exploring where (and what) the problems really are. To begin with perhaps just a simple query displaying the returned rowset without data binding.
I suggest installing the latest version of MDAC and Jet. While Jet used to be a part of the MDAC, I'm pretty sure they dropped it into its own installl/update/service pack at this point. Perhaps start here: http://support.microsoft.com/kb/239114

How to determine at runtime if I am connected to production database?

OK, so I did the dumb thing and released production code (C#, VS2010) that targeted our development database (SQL Server 2008 R2). Luckily we are not using the production database yet so I didn't have the pain of trying to recover and synchronize everything...
But, I want to prevent this from happening again when it could be much more painful. My idea is to add a table I can query at startup and determine what database I am connected to by the value returned. Production would return "PROD" and dev and test would return other values, for example.
If it makes any difference, the application talks to a WCF service to access the database so I have endpoints in the config file, not actual connection strings.
Does this make sense? How have others addressed this problem?
Thanks,
Dave
The easiest way to solve this is to not have access to production accounts. Those are stored in the Machine.config file for our .net applications. In non-.net applications this is easily duplicated, by having a config file in a common location, or (dare I say) a registry entry which holds the account information.
Most of our servers are accessed through aliases too, so no one really needs to change the connection string from environment to environment. Just grab the user from the config and the server alias in the hosts file points you to the correct server. This also removes the headache from us having to update all our config files when we switch db instances (change hardware etc.)
So even with the click once deployment and the end points. You can publish the a new endpoint URI in a machine config on the end users desktop (I'm assuming this is an internal application), and then reference that in the code.
If you absolutely can't do this, as this might be a lot of work (last place I worked had 2000 call center people, so this push was a lot more difficult, but still possible). You can always have an automated build server setup which modifies the app.config file for you as a last step of building the application for you. You then ALWAYS publish the compiled code from the automated build server. Never have the change in the app.config for something like this be a manual step in the developer's process. This will always lead to problems at some point.
Now if none of this works, your final option (done this one too), which I hated, but it worked is to look up the value off of a mapped drive. Essentially, everyone in the company has a mapped drive to say R:. This is where you have your production configuration files etc. The prod account people map to one drive location with the production values, and the devs etc. map to another with the development values. I hate this option compared to the others, but it works, and it can save you in a pinch with others become tedious and difficult (due to say office politics, setting up a build server etc.).
I'm assuming your production server has a different name than your development server, so you could simply SELECT ##SERVERNAME AS ServerName.
Not sure if this answer helps you in a assumed .net environment, but within a *nix/PHP environment, this is how I handle the same situation.
OK, so I did the dumb thing and released production code
There are a times where some app behavior is environment dependent, as you eluded to. In order to provide this ability to check between development and production environments I added the following line to global /etc/profile/profile.d/custom.sh config (CentOS):
SERVICE_ENV=dev
And in code I have a wrapper method which will grab an environment variable based on name and localize it's value making it accessible to my application code. Below is a snippet demonstrating how to check the current environment and react accordingly (in PHP):
public function __call($method, $params)
{
// Reduce chatter on production envs
// Only display debug messages if override told us to
if (($method === 'debug') &&
(CoreLib_Api_Environment_Package::getValue(CoreLib_Api_Environment::VAR_LABEL_SERVICE) === CoreLib_Api_Environment::PROD) &&
(!in_array(CoreLib_Api_Log::DEBUG_ON_PROD_OVERRIDE, $params))) {
return;
}
}
Remember, you don't want to pepper your application logic with environment checks, save for a few extreme use cases as demonstrated with snippet. Rather you should be controlling access to your production databases using DNS. For example, within your development environment the following db hostname mydatabase-db would resolve to a local server instead of your actual production server. And when you push your code to the production environment, your DNS will correctly resolve the hostname, so your code should "just work" without any environment checks.
After hours of wading through textbooks and tutorials on MSBuild and app.config manipulation, I stumbled across something called SlowCheetah - XML Transforms http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5 that did what I needed it to do in less than hour after first stumbling across it. Definitely recommended! From the article:
This package enables you to transform your app.config or any other XML file based on the build configuration. It also adds additional tooling to help you create XML transforms.
This package is created by Sayed Ibrahim Hashimi, Chuck England and Bill Heibert, the same Hashimi who authored THE book on MSBuild. If you're looking for a simple ubiquitous way to transform your app.config, web.config or any other XML fie based on the build configuration, look no further -- this VS package will do the job.
Yeah I know I answered my own question but I already gave points to the answer that eventually pointed me to the real answer. Now I need to go back and edit the question based on my new understanding of the problem...
Dave
I' assuming yout production serveur has a different ip address. You can simply use
SELECT CONNECTIONPROPERTY('local_net_address') AS local_net_address

Symfony 2: Build own DB access layer

I'm new here and on a research trip. We would like to use Symfony2 for a new project.
Now we have the problem that we need to use a company wide self-developed DB access layer.
We don't want to lose the whole Symfony/Doctrine layer for handling data.
Our idea is now to create or overwrite database access layer below Doctrine.
Something like creating a bridge (like PDO) between Doctrine and our DB access layer.
Has anyone an idea how we can do this or maybe someone has done similar things already and can provide us with an how-to?
Please no questions why. We just have to use the company access layer!
Thank you
http://forum.symfony-project.org/viewtopic.php?f=23&t=37637
I found the solution in Doctrine2 doc. It's pretty easy.
I needed for development and testing (frontend and console) about half a day
I've done it in 4 steps:
copy Doctrine\DBAL\Driver\OCI8 to a new folder.
rename files.
change functions to use own database access layer.
add in config file
doctrine:
dbal:
driver_class: /Path/To/Driver/Class
Doctrine has not much but a bit of information about Abstraction Layer:
Supporting Other Databases
If you believe this ยง of the doctrine documentation, you can see that you may use the Common package because it does not require the DBAL. Sadly, the same thing cannot be said of the ORM package. The best thing to do is probably to fork this package so that it supports your own DBAL.
Condolences for being obliged to use this DBAL.

Resources