These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
12Next page
 

SDE and IEC for Crucible 1.1 (now with DB conversions)

Author
Desmont McCallock
#1 - 2012-01-24 17:38:48 UTC  |  Edited by: Desmont McCallock
Static Data Export

IEC Types
IEC Renders
IEC Icons

Change Log:

-- CHANGED IN CRUCIBLE 1.1

-- Removed table agtConfig, all info should be available in agtAgents
-- Removed table translationLaguages, it should never have existed. Proper name is trnTranslationLanguages.
-- Removed column sceneID from mapLocationScenes and replaced it with graphicID representing the nebula graphic.

MySQL 5.5 : cru11-mysql5-innoDB-v1.7z
Luminocity's version: crucible1.1.334471-mysql5-v1.zip
Jercy's Fravowitz version: cru110-mysql5-v1.sql.bz2

PostgreSQL 9: cru11-pgsql9-v1.7z
Jercy's Fravowitz version: cru110-pgsql-v1.sql.bz2

SQLite 3: cru11-sqlite3-v1.db.7z
Jercy's Fravowitz version: cru110-sqlite3-v1.db.bz2
Notice: Not compatible with EAM.

SQLite3 for EAM: cru11-sqlite3-eam-v1.db.7z

P.S: I would like to apologize to CCP Stillman for "stealing" his work.
P.S. 2: Many thanks to Chribba for file hosting services.
P.S. 3: Don't forget to "Like". After all, we live for a reputation Roll.
Kaladr
Viziam
Amarr Empire
#2 - 2012-01-24 18:42:39 UTC
Excellent. Now if the dumps didn't actually require MSSQL Sad

/awaits SQLite conversion

Creator of EVE-Central.com, the longest running EVE Market Aggregator

Artctura
Perkone
Caldari State
#3 - 2012-01-24 19:02:12 UTC
Swap stickies with the 1.0 post. And yes, awaiting mysql conversion.
Zagdul
Virtual Progression
#4 - 2012-01-24 19:33:25 UTC
CCP: Please convert these to MYSQL / SQLite for us

Thanks!

Dual Pane idea: Click!

CCP Please Implement

6ie
The Kiwis
#5 - 2012-01-24 20:01:51 UTC
Thank you very much!
MYSQL Dump imported without error.
I 'Liked'!
D Program
#6 - 2012-01-24 21:08:20 UTC
Yes yes, thank you!

What is this sorcery?

http://www.eve-cost.eu

Matalok
Slackers and Nihilists
#7 - 2012-01-25 19:11:40 UTC
Thank you for saving me from the horrors of MSSQL db conversion.
Louis Vitton
Viziam
Amarr Empire
#8 - 2012-01-25 20:44:51 UTC
Thank you :)
Drapko Nitzhonot
Abdera Logistics
#9 - 2012-01-26 04:05:47 UTC
Thank you for MySQL!!!
Callean Drevus
Perkone
Caldari State
#10 - 2012-01-26 19:51:45 UTC
MySQL with capitalization would be very nice as well... but thanks anyway! Cool

Developer/Creator of EVE Marketeer

Desmont McCallock
#11 - 2012-01-26 19:57:07 UTC
I'm under the impression that "all lower" is MySQL standard. Have I missed something?
Ramov Tinoga
Tinoga Enterprises
#12 - 2012-01-27 09:15:28 UTC
It depends.. For InnoDB probably yes.
Previous conversions (with the tables using MyISAM if I'm not mistaken) offered mixed capitalization which was useful for easier reading on my Linux MySQL, but I make my scripts non-portable when I use it like that. Bear

Many thanks for the conversion!


Callean Drevus wrote:
MySQL with capitalization would be very nice as well... but thanks anyway! Cool


If you want the old table name capitalization back, you can use this script:
Arrowhttp://pastebin.com/0jwhPfNm

NOTE: This is only useful for DB admins that have their mysql database on case sensitive file systems on LInux or UNIX.
Desmont McCallock
#13 - 2012-01-27 09:31:33 UTC
Last conversion provided by Jercy Fravowitz (incarna 1.4), which was using MyISAM engine, had no capitalization.
So I tried to keep some compatibility on that.
As for the engine selection, asking around people that know more than me about MySQL and doing some search on the web, I was convinced that InnoDB is preferred, and should be used, over MyISAM.
Luminocity
The Dark Revenants
PLEASE NOT VIOLENCE OUR BOATS
#14 - 2012-01-27 13:51:14 UTC  |  Edited by: Luminocity
Here's another MySQL 5 export with camelCase table name capitalization, no extended inserts and MyISAM engine like the one's I've made before:
crucible1.1.334471-mysql5-v2.zip

Enjoy!

EDIT: There was a problem with a foreign key of the translations table. This has been fixed in v2
Aineko Macx
#15 - 2012-01-27 15:09:19 UTC  |  Edited by: Aineko Macx
The (non) capitalization is related to the case sensitiveness of the underlying file system. The windows FSs are not, therefore MySQL under Windows is table case insensitive as well and it defaults to lower case.

As for MyISAM and InnoDB, since this is a static data set, there is limited benefit from using InnoDB for these tables. Your application tables can ofc still use InnoDB and benefit from transactions, foreign keys (they can point to SDE MyISAM tables), etc.

Tho having the FKs in the SDE helps in understanding the DB schema Cool
Desmont McCallock
#16 - 2012-01-27 15:28:55 UTC
Aineko Macx wrote:
...benefit from transactions, foreign keys (they can point to MyISAM tables), etc.
Exactly the reason for choosing InnoDB as engine of my MySQL conversions.

Thanks, Aineko (here catch a "Like").
Jercy Fravowitz
School of Applied Knowledge
Caldari State
#17 - 2012-01-27 20:51:05 UTC
Desmont McCallock wrote:
Last conversion provided by Jercy Fravowitz (incarna 1.4), which was using MyISAM engine, had no capitalization.
*cough* i am not even sure where to start there...

a) Incarna 1.4? unless i missed something, there was no Incarna 1.4 dump. there was, however, Incursion 1.4 ...

b) just because i dont post them doesnt mean they dont exist. Ruziel posted links to my inca10, and according to my traffic stats enough people found inca11, cru10b and cru110 ...

c) no, i do not change the capitalization provided by ccp. if they call it invTypes, i will keep the capital T. assuming you meant Incursion 1.4 in your allegation, take a close look at the inc14-mysql-schema ...

d) for the "myisam vs innodb", i am going with a pragmatic solution that "should work for most people reasonably well". the main dump is myisam with no-autocommit and no-extended-inserts.
myisam is what most people want anyways (i tend to run myisampack on mine), the no-ext-ins means it will work in weird webloader-scripts, and the no-ac means it will be less slow.
for the innodb users, there is update-innodb.sql which converts the tables to innodb one by one, and adds FKs. this approach has been about 1.5 orders of magnitude faster than trying to load with no-ext-ins-but-ac into innodb directly.

e) while i am attentionwhoring here, could those of you who know what invTypes is without having to ask google and are going to attend fanfest please briefly pay attention to this and post if interested in the drinking part?
Desmont McCallock
#18 - 2012-01-28 10:20:00 UTC
1. Yes the correct reference is Incursion 1.4 and not Incarna (my bad).

2. As I have mentioned I'm fairly new in the DB conversion business and the only reason I got involved is because you (Jercy) stopped posting the links (and driving some users mad). Now that I know that you keep doing them, I'll do a better search (or guessing) of where you have the files in your server and will stop doing them myself. So people no more DB conversions from me but I'll keep trying to provide the links from Jercy's DB conversions, if noone else does.
Drapko Nitzhonot
Abdera Logistics
#19 - 2012-01-28 12:03:49 UTC  |  Edited by: Drapko Nitzhonot
Desmont McCallock wrote:
2. As I have mentioned I'm fairly new in the DB conversion business and the only reason I got involved is because you (Jercy) stopped posting the links (and driving some users mad). Now that I know that you keep doing them, I'll do a better search (or guessing) of where you have the files in your server and will stop doing them myself. So people no more DB conversions from me but I'll keep trying to provide the links from Jercy's DB conversions, if noone else does.


I prefer "clear" (not hidden, with date and time build) dumps. Please Desmont, don't stop doing them!
6ie
The Kiwis
#20 - 2012-01-28 12:28:48 UTC
Thank you guys for doing these now and in the past. The MySQL conversions work brilliantly and without them I would not be able to make ~1billion ISK per day. (I wish).
12Next page