CakePHP has a process (schema shell and files) for sharing database structure between developers. However, there is often need to share some data (e.g. default user groups) as well. How have you solved this?
You can use fixtures for this. fixtures are small sets of data that can be used for testing or developing purposes. There is an interesting article about this here:
http://nuts-and-bolts-of-cakephp.com/tag/cake-fixtures/
There are also plugins which help with the whole db migration process though I didn't try them out yet you might find them interesting:
http://cakedc.com/pierre_martin/2010/02/05/cakephp-migrations-plugin-easily-version-and-deploy-whole-applications
Related
I was working on a project which is already advanced, specially the database, that has been filled by someone from my team, even though part of it has not been used yet. Some tables can be emptied and refilled as it's sample data, however most of them contains data which will be actually used or it's been used in the parts we're doing now.
The project started in CodeIgniter, by we've realized that Laravel can save us hours of work, so we're planning to migrate it. The point is that we didn't use the CodeIgniter's migration system, and we've seen in the Laravel documentation that only the table structure will be migrated, plus we have to create every migration.
The question here is if there's a way to both, create the migratinos files automatically, and to keep the relevant data that will be used in the application so we don't need to refill the database again (yep, there are kind of big tables). We thought on the seeders, but what we've seen is that they only store sample data...
You can use Laravel migration generator. It will simply help you to generate migrations from your
existing database. Check it out below. You will find in readme how to use it. Good luck.
https://github.com/Xethron/migrations-generator
Hope , it helps. Thanks. Cheers. -_-
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.
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.
So I have been looking around the internet for a good explanation of how lift works concerning databases. I have not found anything very helpful yet. What I am looking for is a simple explanation or code example that can show how lift connects to its databases to perform transactions and how to use this to create new tables, models or update and edit existing tables.
For example: with django i fairly easily figured out how it generated database tables from model classes and executed updates on them through methods it inherited from the framework.
I am trying to create a simple app at the moment that would have users, information about them, posts on a website, etc.
I am currently reading through the available Lift books and would greatly appreciate more help in learning how to use lift.
Lift configures it's data source in Boot.scala.
if (!DB.jndiJdbcConnAvailable_?) {
val vendor =
new StandardDBVendor(Props.get("db.driver") openOr "org.h2.Driver",
Props.get("db.url") openOr
"jdbc:h2:lift_proto.db;AUTO_SERVER=TRUE",
Props.get("db.user"), Props.get("db.password"))
LiftRules.unloadHooks.append(vendor.closeAllConnections_! _)
DB.defineConnectionManager(DefaultConnectionIdentifier, vendor)
}
It can generate table schemas for you using Schemifier:
Schemifier.schemify(true, Schemifier.infoF _, User,Post,Tag,PostTags)
For general Lift project, you can just use Lift Mapper as an ORM tool, it's not complete but works for most of the cases.
You can refer to Lift WIKI and Simply Lift(Written by the Author) or Explore Lift.
From my perspective, the documents available so far are rather disappointing.
It's said the Lift in Action is very well written, but won't come out till this summer, you can read it from MEAP.
In the Exploring Lift book, the PocketChange example contains code showing how to define a User using MetaProtoUser and other features. I would start there for a better understanding of Lift, model and the built-in CRUD and User prototype objects.
http://exploring.liftweb.net/master/index-2.html#toc-Chapter-2
Keep in mind that the 'new' approach to DB integration will be via the Record. This is very much a work in progress, so I wouldn't rush to start learning it.
You can also look at the source for Lift in Action to get some ideas. Here's a link to the travel app built in the first couple chapters
https://github.com/timperrett/lift-travel
And to the source code for the entire book. Chapter 10 is the Mapper chapter.
https://github.com/timperrett/lift-in-action
The default ORM in Lift is Mapper which gives you among other things a quick path to CRUD functionality for your DB entities.
However if you would like a more traditional JPA persistence approach (or rather SPA since entities would in that case be written in scala), i usually find very useful the JPA-like sample application that is part of the Lift distribution. To try it out, assuming maven is installed, just type:
mvn archetype:generate -DarchetypeRepository=http://scala-tools.org/repo-snapshots -DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-archetype-jpa-basic_2.8.1 -DarchetypeVersion=2.3-SNAPSHOT -DgroupId=org.mycompany.myproject -DartifactId=MyProject -Dversion=1.0
This will create a MyProject Lift project, containing a simple library application with 2 entities (Author and Book) having a one-to-many relationship as well as CRUD snippets showing how you can create and edit such entities in a jdbc compliant database.
We currently use an SVN repository to ensure everyone's local environments are kept up-to-date. However, Drupal website development is somewhat trickier in that any custom code you write (for instance, PHP code written for a node body) is stored in the DB and the changes aren't recognized by the SVN working copy.
There are a couple of developers who are presently working on the same area of a Drupal site, but we're uncertain about how to best merge our local Drupal database changes together. Committing patches of database dumps seem clumsy at best and is most likely inefficient and error-prone for this purpose.
Any suggestions about how to approach this issue is appreciated!
Unfortunately, database deployment/update is one of Drupals weak spots. See this question & answers as well as this one for some suggestions on how to deal with it.
As for CCK, you could find some hints here.
As for php code in content, I agree with googletorp in that you should avoid doing this. However, if for some reason you absolutely have to do it, you could try to reduce the code to a simple function call. Thus you'd have the function itself in a module (and this would be tracked via SVN). But then you are only a little step from removing the need for the inline code anyways ...
If you are putting php code into your database then you are doing it wrong. Some stuff are inside the database like views and cck fields plus some settings. But if you put php code inside the node body you are creating a big code maintenance problem. You should really use the API and hooks instead. Create modules instead of ugly hacks with eval etc.
All that has been said above is true and good advice.. To answer your practical question, there are a number of recent modules that you could use to transport the changes done by the various developers.
The "Features" modules is a cure the the described issue of Drupal often providing nice features, albeit storing lots of configs and structure in the DB. This module enables you to capture a feature and output it as a pseudo-module (qualifies as a module with .info and code-files and all). Here is how it works:
Select functionality/feature to export
The module analyses the modules, files, DB content that is required to rebuild that feature elsewhere
The module creates a pseudo-module that contains the instructions in #3 and outputs everything (even SQL to rebuild the stuff in the DB) into a module package (as well as sets dependencies for other modules required)
Install the pseudo-module on your new site and enable it
The pseudo-module replicates the feature you exported rebuilding DB data and all
And you can tell your boss you did it all manually with razor focus to avoid even 1 error ;)
I hope this helps - http://drupal.org/project/features
By committing patches of database dumps, do you mean taking an entire extract of the db and committing it after each change?
How about a master copy of the database? Extract all tables, views, sps, etc... into individual files, put them into svn and do your merge edits on the individual objects?