I'm in the process of upgrading to the new SEOW before we start our next campaign. The notes indicate the old DB files are not compatiable with the new MP and DCS. When I go get the new SEDB32 file from the below link it appears to only be a partial file. Is there a different file other than the Sardegna patch that I need to download?
http://sourceforge.net/project/showfile ... _id=115125
MySQL DB
Moderator: SEOW Developers
-
VT-51_Thud
- Posts: 142
- Joined: Sun 21 Jan 2007 10:20 am
- Location: Virginia, USA
- Contact:
-
VT-51_Thud
- Posts: 142
- Joined: Sun 21 Jan 2007 10:20 am
- Location: Virginia, USA
- Contact:
Ahh, never mind...I found the answer in this thread.... http://seowhq.net/seowforum/viewtopic.php?t=475
-
VT-51_Thud
- Posts: 142
- Joined: Sun 21 Jan 2007 10:20 am
- Location: Virginia, USA
- Contact:
Should the Lite versions be available at the download site too? I don't see them. I'm looking for the SEDB32_NewGuineaLite.sql.
From the readme....
Lite versions are also supplied for each sector. These contain only information relevant to the sector, thus giving improved
efficiency for administration and query performance. For all the Lite versions, the individual databases can only support
campaign operations in the relevant sector. The standard SQL versions are:
SEDB32_ArdennesLite.sql
SEDB32_BerlinLite.sql
SEDB32_CrimeaLite.sql
SEDB32_CyrenaicaLite.sql
SEDB32_EnglishChannelLite.sql
SEDB32_FortressMaltaLite.sql
SEDB32_GothicLineLite.sql
SEDB32_GuadalcanalLite.sql
SEDB32_GulfOfFinlandLite.sql
SEDB32_HawaiiLite.sql
SEDB32_ImphalLite.sql
SEDB32_ItalyLite.sql
SEDB32_IwoJimaLite.sql
SEDB32_KhalkhinGolLite.sql
SEDB32_KubanLite.sql
SEDB32_KurlandLite.sql
SEDB32_KurskLite.sql
SEDB32_KyushuLite.sql
SEDB32_LibyaLite.sql
SEDB32_LvovLite.sql
SEDB32_MaltaLite.sql
SEDB32_ManchuriaLite.sql
SEDB32_MarianasLite.sql
SEDB32_MediterraneanLite.sql
SEDB32_MidwayLite.sql
SEDB32_MoscowLite.sql
SEDB32_MurmanskLite.sql
SEDB32_NewGuineaLite.sql
SEDB32_NormandyLite.sql
SEDB32_NorthSeaLite.sql
SEDB32_OkinawaLite.sql
SEDB32_OsloLite.sql
SEDB32_OstfrieslandLite.sql
SEDB32_ProkhorovkaLite.sql
SEDB32_SingaporeLite.sql
SEDB32_SlovakiaLite.sql
SEDB32_SmolenskLite.sql
SEDB32_StalingradLite.sql
SEDB32_TubruqLite.sql
SEDB32_TunisLite.sql
From the readme....
Lite versions are also supplied for each sector. These contain only information relevant to the sector, thus giving improved
efficiency for administration and query performance. For all the Lite versions, the individual databases can only support
campaign operations in the relevant sector. The standard SQL versions are:
SEDB32_ArdennesLite.sql
SEDB32_BerlinLite.sql
SEDB32_CrimeaLite.sql
SEDB32_CyrenaicaLite.sql
SEDB32_EnglishChannelLite.sql
SEDB32_FortressMaltaLite.sql
SEDB32_GothicLineLite.sql
SEDB32_GuadalcanalLite.sql
SEDB32_GulfOfFinlandLite.sql
SEDB32_HawaiiLite.sql
SEDB32_ImphalLite.sql
SEDB32_ItalyLite.sql
SEDB32_IwoJimaLite.sql
SEDB32_KhalkhinGolLite.sql
SEDB32_KubanLite.sql
SEDB32_KurlandLite.sql
SEDB32_KurskLite.sql
SEDB32_KyushuLite.sql
SEDB32_LibyaLite.sql
SEDB32_LvovLite.sql
SEDB32_MaltaLite.sql
SEDB32_ManchuriaLite.sql
SEDB32_MarianasLite.sql
SEDB32_MediterraneanLite.sql
SEDB32_MidwayLite.sql
SEDB32_MoscowLite.sql
SEDB32_MurmanskLite.sql
SEDB32_NewGuineaLite.sql
SEDB32_NormandyLite.sql
SEDB32_NorthSeaLite.sql
SEDB32_OkinawaLite.sql
SEDB32_OsloLite.sql
SEDB32_OstfrieslandLite.sql
SEDB32_ProkhorovkaLite.sql
SEDB32_SingaporeLite.sql
SEDB32_SlovakiaLite.sql
SEDB32_SmolenskLite.sql
SEDB32_StalingradLite.sql
SEDB32_TubruqLite.sql
SEDB32_TunisLite.sql
-
IV/JG7_4Shades
- Posts: 2211
- Joined: Mon 08 Jan 2007 11:10 pm
- Location: Perth, Western Australia
Hi Thud,
Oh, I forgot to change the README. If you open the latest DB zip file, you will see that each sector has a choice of 2 SQL files - one in standard format and one in "extended inserts" format. Both of these contain what was once called a "Lite" data load. You can choose which format you want to use. If you use Navicat, for example, I'd recommend the "extended inserts" format for fastest loading.
Cheers,
4Shades
Oh, I forgot to change the README. If you open the latest DB zip file, you will see that each sector has a choice of 2 SQL files - one in standard format and one in "extended inserts" format. Both of these contain what was once called a "Lite" data load. You can choose which format you want to use. If you use Navicat, for example, I'd recommend the "extended inserts" format for fastest loading.
Cheers,
4Shades
IV/JG7_4Shades
SEOW Developer
SEOW Developer
-
VT-51_Thud
- Posts: 142
- Joined: Sun 21 Jan 2007 10:20 am
- Location: Virginia, USA
- Contact:
SEOW MP performance improvement
Hi 4Shades,
perhaps a suggestion for performance improvement in Seow MP.
Currently it looks as if every time a pilot connects to the schedule page, all data from the database is queried and displayed every time a pilot is switching to the features of planning.
This is not always necessary. As long as nothing changed in the planning, or new flights were tasked, there is neither the need to fetch all of the data from the database, nor to generate new queries for all to the mission planner connected pilots.
My suggestion:
- caching of relevant data
- use of session management (regarding data caching)
- no unnecessary DB queries
This is no offence, 4Shades, you did a great job by doing all this SEOW stuff, just some of my thoughts
And, if you are interested:
I did some considerations regarding the workflow of mission planning, maybe there is improvement potential, too.
Again:
I think your work and the idea of this IL2 extension is just awesome.
regards,
Scimitar
perhaps a suggestion for performance improvement in Seow MP.
Currently it looks as if every time a pilot connects to the schedule page, all data from the database is queried and displayed every time a pilot is switching to the features of planning.
This is not always necessary. As long as nothing changed in the planning, or new flights were tasked, there is neither the need to fetch all of the data from the database, nor to generate new queries for all to the mission planner connected pilots.
My suggestion:
- caching of relevant data
- use of session management (regarding data caching)
- no unnecessary DB queries
This is no offence, 4Shades, you did a great job by doing all this SEOW stuff, just some of my thoughts
And, if you are interested:
I did some considerations regarding the workflow of mission planning, maybe there is improvement potential, too.
Again:
I think your work and the idea of this IL2 extension is just awesome.
regards,
Scimitar
-
IV/JG7_4Shades
- Posts: 2211
- Joined: Mon 08 Jan 2007 11:10 pm
- Location: Perth, Western Australia
Hi Scimitar,
You are 100% correct, data caching would make things more efficient.
It would also be neat if regular partial/contextual refreshes could be made using timed or event-driven Ajax callbacks or similar.
Some of the caching functionality can be handled by MySQL's query cache, which can be very efficient. But more could be done inside the MP. It all comes down to how quick and easy it is to work out if "nothing changed in the planning". This would involve contextual scans of ObjMissionData table, recon reports, offmap fuel, airbases, railway stations, supply drops, resupply points, reinforcements, industrial installations plus a few other things, since all of these can be altered dynamically by other commanders, friendly and enemy.
If I knew then (2003) what I know now (2009), I would have structured the MP very differently. The good thing about the MP now is that it is reasonably modular, i.e. the SQL is fairly well separated from the core Javascript code and communication is by simple strings, POSTs and GETs. The bad thing is that it could be more object-oriented and cross-browser compatible. But, most importantly, I have run out of energy for major changes now. The MP is open source, of course, so please feel free to kick around in the code and test your ideas. If you want to create a new branch in the CVS tree, just let me know and I'll give you permissions to do so. I always welcome anyone who wants to get involved.
Cheers,
4Shades
You are 100% correct, data caching would make things more efficient.
It would also be neat if regular partial/contextual refreshes could be made using timed or event-driven Ajax callbacks or similar.Some of the caching functionality can be handled by MySQL's query cache, which can be very efficient. But more could be done inside the MP. It all comes down to how quick and easy it is to work out if "nothing changed in the planning". This would involve contextual scans of ObjMissionData table, recon reports, offmap fuel, airbases, railway stations, supply drops, resupply points, reinforcements, industrial installations plus a few other things, since all of these can be altered dynamically by other commanders, friendly and enemy.
If I knew then (2003) what I know now (2009), I would have structured the MP very differently. The good thing about the MP now is that it is reasonably modular, i.e. the SQL is fairly well separated from the core Javascript code and communication is by simple strings, POSTs and GETs. The bad thing is that it could be more object-oriented and cross-browser compatible. But, most importantly, I have run out of energy for major changes now. The MP is open source, of course, so please feel free to kick around in the code and test your ideas. If you want to create a new branch in the CVS tree, just let me know and I'll give you permissions to do so. I always welcome anyone who wants to get involved.
Cheers,
4Shades
IV/JG7_4Shades
SEOW Developer
SEOW Developer
Hi 4Shades,
to be honest: I knew you would respond like you have done
I can see your point, and as long as you are, more or less, alone in developing SEOW core features, its pretty hard to get rid of todo lists
I like the idea to get involved in this stuff very much. Currently I'm busy with two other projects in my spare time, and I'm not very deep into SEOW yet (from development point of view).
We should stay in touch about this. In approximately one or two month I will have enough spare time to get deeper into SEOW development.
From then I could help you out to "charge your batteries" seriously
In the meantime:
Do you have any design or architectual documentations? If so, I could do some small bugfixes by myself, like the "DBnull" issue. Its just pretty hard and takes too much time for me, to get into foreign code by "try and error"
regards,
Scimitar
to be honest: I knew you would respond like you have done
I can see your point, and as long as you are, more or less, alone in developing SEOW core features, its pretty hard to get rid of todo lists
I like the idea to get involved in this stuff very much. Currently I'm busy with two other projects in my spare time, and I'm not very deep into SEOW yet (from development point of view).
We should stay in touch about this. In approximately one or two month I will have enough spare time to get deeper into SEOW development.
From then I could help you out to "charge your batteries" seriously
In the meantime:
Do you have any design or architectual documentations? If so, I could do some small bugfixes by myself, like the "DBnull" issue. Its just pretty hard and takes too much time for me, to get into foreign code by "try and error"
regards,
Scimitar
-
IV/JG7_4Shades
- Posts: 2211
- Joined: Mon 08 Jan 2007 11:10 pm
- Location: Perth, Western Australia
Hi Scimitar,
After the upcoming "Philippines" release, which I think removes the DBNull error on reinforcement flights (I can't reproduce it with my current codeset), I will build some clean CVS images for the DCS and MP.
Unfortunately, no design/architectural documentation exists!
That's also on the "to do" list. It is firmly in the "big ball of mud" paradigm.
Cheers,
4Shades
After the upcoming "Philippines" release, which I think removes the DBNull error on reinforcement flights (I can't reproduce it with my current codeset), I will build some clean CVS images for the DCS and MP.
Unfortunately, no design/architectural documentation exists!
That's also on the "to do" list. It is firmly in the "big ball of mud" paradigm.Cheers,
4Shades
IV/JG7_4Shades
SEOW Developer
SEOW Developer