Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 34

Thread: Instruction script commands Installation/Deinstallation

  1. #21

    Default

    Quote Originally Posted by Razo[R]apiD View Post
    I'd add Remarks fields so we can type some specific stuff there, like: "This mod can be incomaptible with mod XX or mod YY" or "This mod uses this and that, make sure to ......"
    Ok yep makes sense will get that added - that kind of fell under the AAAA comments but also that needs sorting

  2. #22

    Default

    Quote Originally Posted by JoTo View Post
    imo there should be only one central database, and not 2 which needs to be synced and stuff. Whats the purpose of having 2 databases ? And then syncing ? omg no please.

    To the database field names: Make the names please more universal, at current you have

    print("MOD Version = "); print $db_field['field_modversion_value'] . "<BR>";

    and I assume you have the same for maps like this

    print("MAP Version = "); print $db_field['field_mapversion_value'] . "<BR>";

    make it universal so you can take the same database table layout for all content

    print("MAP Version = "); print $db_field['field_contentversion_value'] . "<BR>";
    print("MOD Version = "); print $db_field['field_contentversion_value'] . "<BR>";

    If we build further on that database it would be extra work to handle 2 database fields which are basically the same.

    When external tools or a webservices accesses the database it doesn't matter if its a map or mod, a specific field in the database will tell what type of content it is.

    I think you need to add an extra field for that like: ContentType
    which contains then wether Map or Mod or w/e
    Hi Joto think you have missed a few posts on the other threads before they moved from the big plan but a lot of this has already been raised but that does not mean it cant change )))

    So to go through your concerns -:

    imo there should be only one central database, and not 2 which needs to be synced and stuff. Whats the purpose of having 2 databases ? And then syncing ? omg no please.
    Well It is a central database its home will be X-null and AAAA - The reason for the sync and replication is 2 fold -:

    1. The Central database needs a fall back so if it goes down on X-null or X-null closes down then the fall back will be AAAA and vice a versa.

    2. Any large project like this should have a fall back so the database would need replication anyway.

    3.The purpose is not to start another project from scratch again - I spent 12 months on the Map and mod Database already and thats what it is a database so the DATA can be used and accessed anywhere which is where we are.

    4. The point is I am happy with the AAAA concept it works but I appreciate that not all like the way AAAA is displayed so the whole point was to use the database.

    5. Why would I scrap AAAA Database when it already is a great solution IMO All we are trying to do is to present the data as X-null and share the data and build on it with the patch functions.

    6. The Field names are built on Drupal framework but they are flexible I have changed yours as you requested but they are just field names you still have to present txt to the field as a title as field names are low level and cant have spaces or characters that are limited so as long as the field names explain what they are I dont see any major issue but I am not going to change all the existing fields as their would be no overall benefit IMO

    7. The Database - You have already asked me to do 2 separate databases for Map and mods on the other thread - I understand what you are saying on the field names to not include mod and map etc but works both ways it helps to know the field data is for maps and mods just how I structured it for ease.
    Their are a few different fields across maps and mods that are not generic hence the 2 separate Databases.........You could go full circle and say well why need two databases if you can add "type of Mod or Map" - I could but it works both ways someone else could raise an issue and say well mods and maps should be separate


    I understand what you are saying about the field names in code as having to change them for maps or mods but at the same time you asked for talking fields to help so kind of could get confusing in code if you have data from maps and not mods because both field names are the same..................

    It would be just a case of what ever code you use for maps and mods is to replace "mods" and "maps" with any txt editor and their will be a few different fields across both that maps and mods dont both need

    I guess I am just trying to build a data base that can be built on So as I see it will be displayed different on AAAA to X-null but its just Data The only Problem I got is getting the replication to work - The only things I ask is the existing field names remain the same we can add more I just dont want to end up running AAAA and X-null separate for the same goals..................
    Last edited by heatsinkbod; September 1st, 2012 at 09:48 AM.

  3. #23
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Well, the fallback thing is good. Syncing changes on the fly won't be that hard. You will just have to create a logic, that will save entries in both databases.

    But the hard part comes, when one DB is down, and you add a lot of entries in the other one. Now when let's say xNULL DB goes up again, we need to sync it automatically, so we need to make a diff on both DBs to copy the changes.

    I'd go for a separate table for this that will keep the history of changes, and DB version.

    It would work like this:

    1. You add new mod/map, and you run SQL query on the logic backend that inserts a new row into DB. In the same time, you save that SQL query to a history revision table under new date and DB version.

    2. Now when one DB is down and goes up again, it checks the second DB (with Cron job or something), gets the latest DB version number and compares it with it own version.
    3. When they don't match, it takes all DB versions, gets the SQL query from the history, and runs it on itself automatically adding what have been added in AAAA DB until it's up to date with DB version number.

    So I propose that we create a table named db_revisions, db_migrations or db_history that will have 3 fields, DB_VER which will stand for DB version number, QUERY_STRING which will keep the query that was executed in that version, DATE, to keep the date of the change for supervision purposes

  4. #24

    Default

    I didn't see a category or game name field on http://www.mohaaaa.co.uk/AAAAMOHAA/c...tle-server-mod

    I think you've made excellent progress so far heatsink! Great stuff. However, my only critique at the moment is that the way the information is presented about each mod is a bit confusing / unorganized. Perhaps after we get all the changes in, I could work on a more intuitive design?

  5. #25
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    own3mall, check the other thread about the template were I pointed out few things. We could integrate your file manager to manage the files and upload the easly, then it would be easier to create a panel for map/mod DB where you would select the file previously uploaded with your file manager. I'd like it this way because the manager is easy to use, you can set permissions on folders and so on, and you've made some work on it to it would be a shame if it's not used at all. We should combine it with the rest of the project.

  6. #26

    Default

    Quote Originally Posted by own3mall View Post
    I didn't see a category or game name field on http://www.mohaaaa.co.uk/AAAAMOHAA/c...tle-server-mod

    I think you've made excellent progress so far heatsink! Great stuff. However, my only critique at the moment is that the way the information is presented about each mod is a bit confusing / unorganized. Perhaps after we get all the changes in, I could work on a more intuitive design?
    Hi yeh its been added now as Gametype on AAAA - will display but have not updated permissions yet for new records its on the left third block down.

    Yes please on the help this is just basic to get started http://www.x-null.net/forums/showthr...d-map-Template and Razor mentioned a few things to change on that.

    Also I have no index code template to start with as AAAA uses a Database record view's module so no code I can rip on the index so we need to build from fresh on that to list the records and be able to display - Have added Joto's fields but have not included them in the display yet. I can send you the mysql access we are using at present to get the templates built and tested ?

    Also as Razor suggested on the file management - We have no code at present to create records was just going to do this I guess form based but open to idea's suggestions on that.

  7. #27
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    It will be form based, but the File Manager will be used to actually upload the files, and you will just have to select it in the form, from the list of available files. This way we can keep mods more organized on the server. We'll just need to setup a root folder for mods, and made sure that after the file is used, you can't move it or rename unless you delete the record (and add it later with fixed URL) or it should update the file locations and names on the fly. This would be better and own3mall would need to add this to rename, move functions in his file manager.

  8. #28

    Default

    Quote Originally Posted by Razo[R]apiD View Post
    Well, the fallback thing is good. Syncing changes on the fly won't be that hard. You will just have to create a logic, that will save entries in both databases.

    But the hard part comes, when one DB is down, and you add a lot of entries in the other one. Now when let's say xNULL DB goes up again, we need to sync it automatically, so we need to make a diff on both DBs to copy the changes.

    I'd go for a separate table for this that will keep the history of changes, and DB version.

    It would work like this:

    1. You add new mod/map, and you run SQL query on the logic backend that inserts a new row into DB. In the same time, you save that SQL query to a history revision table under new date and DB version.

    2. Now when one DB is down and goes up again, it checks the second DB (with Cron job or something), gets the latest DB version number and compares it with it own version.
    3. When they don't match, it takes all DB versions, gets the SQL query from the history, and runs it on itself automatically adding what have been added in AAAA DB until it's up to date with DB version number.

    So I propose that we create a table named db_revisions, db_migrations or db_history that will have 3 fields, DB_VER which will stand for DB version number, QUERY_STRING which will keep the query that was executed in that version, DATE, to keep the date of the change for supervision purposes
    Hi ok well created those fields but kind of think maybe we are over engineering now thinking about it........

    So been reading a bit more on the MYSQL syncing and Replication but seems if you setup a slave it will autosync its life out so perhaps we should just write direct to AAAA and then slave copy on X-null ? http://www.redips.net/mysql/add-new-slave/
    Perhaps we should just create a replication slave on X-null - So I mean that X-null writes direct to AAAA would save us having to do all of above.......

    http://blog.agoragames.com/blog/2008...a-mysql-slave/
    Last edited by heatsinkbod; September 5th, 2012 at 08:44 AM.

  9. #29
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Is the replication a two-way process or one-way (master->slave only) ? Because we need a two-way solution, and also, we won't be able to do this on xNULL because we are not on a dedi and we don't have any control over mysqld deamon (process) and this is needed to restart the slave and set the config options for whole process.

    Additionally this replication does exactly what we are after. Master saves executed SQL queries into so called log file that Slave downloads and executes to have the same data.

    We'd just keep the queries in a separate table instead of a file, and set 2 Cron jobs that would check the version of the DBs and update

  10. #30

    Default

    Hi Ok well reading so much about it the path I was trying to get my head round was which I thought was the easiest was to write to the existing database then replicate that out so yeh Master and Slave but see what your saying and so many options on what I am reading hard to know best path, you seem to be more up to speed than me so happy to go with your plan

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •