1.  Dump the schema only.  This will  not contain any data, procedures or triggers, but only create info.  This will allow you to easily import your original schema later on.

mysqldump -uroot -proot -d --skip-triggers myDatabase > myDatabase_schema.sql

The -u specifies your username, and must be followed by your username e.g. -uroot. This is the same with your password, -proot.

The -d tells mysqldump to not dump any data in the schema and the –skip-triggers will skip all triggers and procedures.

The myDabase is the name of your database and the > myDatabase_schema.sql is where you want to dump it.

2. Dump the triggers/procedures. This will only contain the triggers and procedures contained within your database.

mysqldump -uroot -proot -d --no-create-info myDatabase > myDatabase_triggers_procs.sql

Here we have a –no-create-info to tell mysqldump that no create statements must be allowed, thus eliminating any schema sql and again the -d parameter to skip all data.

3. Dump the data only without triggers and create statements.

mysqldump -uroot -proot --skip-triggers --no-create-info myDatabase > myDatabase_base_data.sql

Finally we can dump the data only. The –skip-triggers skips all triggers and procedures, whils the –no-create-info skips sql create statements.

This will allow you to have 3 different sql files:

• myDatabase_schema.sql (only contains the schema)
• myDatabase_triggers_procs.sql (only contains triggers/procs)
• myDatabase_base_data.sql (only contains data)

Now to import.

This is fairly trivial.

All you have to remember is to import your data in a sequence.

First the schema, then the triggers and procedures and then finally the base data.  The schema will create your tables, the triggers and procs can then be added to your tables and finally the tables can be populated with data.

1. Import schema

mysql -uroot -proot myDatabase < myDatabase_schema.sql

2. Import triggers/procs

mysql -uroot -proot myDatabase < myDatabase_triggers.sql

3. Import base data

mysql -uroot -proot myDatabase < myDatabase_base_data.sql

And your done.

so for this, i’ve decided on DeviceAtlas.  just head on over to DeviceAtlas and open a developers account – you will get a one year developer’s license to play around to see how cool it is.

after registering – click on the downloads link – then go to the php example and download the source files.  after de-tar-and-un-zipping the file, just extract the contents.  at the moment all we are really interested in, is the Mobi/Mtld/DA directory and its contents – also create a json directory and drop the Sample.json file inside.

dump everything into a web directory somewhere.

create a deviceatlas.php file in the working directory root and put the following inside.

//includes the DeviceAtlas API

include 'Mobi/Mtld/DA/Api.php';//fetch the previously populated apc cache instance into a variable

$tree = apc_fetch('tree');

//Get the properties from a variable containing a JSON tree loaded from cache

$properties = Mobi_Mtld_DA_Api::getProperties($tree, $_SERVER['HTTP_USER_AGENT']);

//Output the phone properties for your viewing pleasure

print_r($properties);

‘hhmmm, that’s it?’, you might ask, and if you were clever you would have noticed something strange in the code above.

yip, that is pretty much it – but you also need caching.  the apc_fetch(‘tree’) command in the code above actually fetches the json file already dumped into a ‘tree’ cache instance in PHP APC (Alternative PHP Cache).

why PHP APC, you may also ask.  well, besides using the overstated memcached (you might want to read this), there are some methods to the madness.  with PHP APC, the cache is shared on a server.  it might not be accessible from other servers, but this is not really a con in my mind.

if you wish to scale your application later one and add another server, there is going to be some issues, you might say – but there will also be issues if you have millions of users hit one central instance of DeviceAtlas.  so, having one instance of DeviceAtlas per server might not be too much of an issue.  also when it comes to updating the json file, you might want to consider the single point of failure issue of just having one server.

so have a couple of servers, and just write some scripts to update the single instances of DeviceAtlas, rather than updating one, already busy server which still needs a cache update.

but, back to business.

first you have to install PHP APC.  i found this handy guide on the net, which helped me install it on my debian system and integrate it with apache and php5 – there is also a guide at the bottom for fedora based machines, so don’t fret my linux loving friends

you can create a php script to run the following – which should cache your DeviceAtlas tree into PHP APC.

//ads the sample json data from DeviceAtlas

apc_add('tree', Mobi_Mtld_DA_Api::getTreeFromFile("json/Sample.json"));

from the first code example, the output might look something like this (depending on your phone)

Array
(
[wmv] => 0
[vendor] => Nokia
[mobileDevice] => 1
[memoryLimitMarkup] => 357000
[memoryLimitDownload] => 61440
[midiMonophonic] => 1
[midiPolyphonic] => 1
[mpeg4] => 1
[3gpp] => 1
[drmOmaForwardLock] => 1
[drmOmaCombinedDelivery] => 1
[drmOmaSeparateDelivery] => 1
[markup.xhtmlMp10] => 1
[markup.xhtmlBasic10] => 1
[image.Jpg] => 1
[image.Png] => 1
[amr] => 1
[mp3] => 1
[aac] => 1
[h263Type0InVideo] => 1
[gprs] => 1
[edge] => 1
[image.Gif87] => 1
[uriSchemeTel] => 0
[qcelp] => 0
[hsdpa] => 0
[amrInVideo] => 1
[3gpp2] => 0
[displayColorDepth] => 18
[model] => N70
[https] => 1
[image.Gif89a] => 0
[umts] => 0
[displayWidth] => 176
[displayHeight] => 208
[markup.xhtmlMp11] => 0
[markup.xhtmlMp12] => 0
[csd] => 0
[hscsd] => 0
[id] => 204255
[_matched] => NokiaN70
[_unmatched] => -1/5.0609.2.0.1 Series60/2.8 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Link/6.3.1.13.0
)

you can view the attribute explanations here

now you can use the phone’s specific properties to your advantage.  you also might want to look at the user agent switcher add-on for firefox for testing purposes.

that’s it.  now every once in a while you can just update the json file, delete the current cache (http://www.php.net/manual/en/function.apc-delete.php) and bob’s your device detecting, apc caching uncle.

so, its been about 2 weeks, my fascination with erlang was as short lived as a teenage holiday romance.  the concurrent language which would probably topple all others if the overheads weren’t so much.  erlang has a huge learning curve, don’t think just cause you dabble in a bit of ruby you will pick up this language in one go

i’m sure it will take a few years of dedication to get the best of this beast.  as for the yaws server i couldn’t find much fault.  and according to tests this is a solid winner.  erlyweb was a bit of a hickup.  from version incompatibilities to the dreaded ‘//’ in the url (i think i might have gotten the sour deal of the experience).

so for now my quest to conquer erlang seem a bit like an empty dream, but my quest continues….with nitrogen…some day

a lot of focus on scalability and performance.  that being said – i’ve decided to be proactive and try out a stack i’m totally unfamiliar with, but apparently with great potential.

lyme – linux, yaws, mysql, erlang

linux - the tried and tested platform, open-source, and where all good things start.

yaws - yet another web server written in erlang, supposedly outperforms apache with throughput and parallel sessions.

mysql – i’m just a big fan, what can i say

erlang -  the language, created as a general purpose, concurrent language

so finally i got my lyme stack running on my machine – so now for the tedious process of evaluating it, and maybe do something like a simple user-to-user subscription service.  like the friends features of facebook

i’ll keep you informed with my findings, with a couple of code examples and a walkthrough of my experience.