Check out all of the details of this month's Patch Notes, featuring the Renovation Season 3 Update! https://mabinogi.nexon.net/news/74541/renovation-season-3-patch-notes-may-26th-2022
[NEW MILLETIANS] Please note that all new forum users have to be approved before posting. This process can take up to 24 hours, and we appreciate your patience.
If this is your first visit, be sure to check out the Nexon Forums Code of Conduct. You have to register before you can post, so you can log in or create a forum name above to proceed. Thank you for your visit!

Alexina Server Merge?

Comments

  • DARKCloudDARKCloud
    Mabinogi Rep: 1,040
    Posts: 39
    Member
    1- I'm sure other content will be implemented during merge update . you just shrugged 2 weeks ago when we had a 12 hour maintenance for no notable changes in player content .

    4-this could definitely be a problem and as a solution I will join alexina to cash in on all the discounted gear from "quitting/transfering sales". Alexina is looking a lot brighter with me there. :)
  • ImaizumiImaizumi
    Mabinogi Rep: 4,215
    Posts: 698
    Member
    Btw there's a reason to have more than 1 channel. You get more raid spawns per day. I think 7 is a reasonable number to have. Especially if all servers got merged.
  • GTCvActiumGTCvActium
    Mabinogi Rep: 7,125
    Posts: 661
    Member
    Helsa wrote: »
    The game may have more added to it over time, but the basic paradigm of why it's is accessing the database to know the relevant server remains the same. If an object is about to perform an action in-game but the server upon which it will happen needs to be known, then what server the object is associated with is read and used appropriately. Whether it says "Ruari" or whether it say "Nao", the action remains the same. Granted, if during the merge they miss editing some of those fields and say leave them as "Ruari" when they should say "Nao", then that will break things. So, if your concern is that the merge might be handled sloppy, I suppose that is possible. But if it is not sloppy, then it'll work: the naming kludge, moving guild stones, and collecting of bank gold issues notwithstanding.

    If you work extensively with databases with complex referencing and foreign keys you would understand that accessing and changing values are a very easy thing, but whether or not the program will run fine after is different issue all together. One big issue I've seen when merging of database is when PKs of FKs are improperly ported over, or even just an small over sight, could result is catastrophic errors to occur. For instance a reference is suppose to point to a unique object, but thanks to a database merge, or an appending of another database, could cause this reference to now point to two or more objects. This has several effects, the more benign one is that it just defaults to the first instance, ignoring the other entries. More damaging effects are if the reference points to further tables and entries which in turn could cascade into corruption of other data which can be extremely difficult to fix. Assuming this only affects a tiny minority, there's the risk that someone could see their account lost for days or weeks at a time while NA considers the merge a success. As a game, the cross references, FKs and other things are bound to be extensive. We are also unsure of the data structure which could mean very well that PKs will have to be done and adjusted for during the actual merge. For example certain aspects might be kept as separate databases with identical tables. A merge of such databases would need mean that any PKs will almost certainly have duplicates in the other databases. Now you may think that just changing these are a simple matter, however when changing these, you must also be weary of also changing FKs of other entries. Missing any of these entries could result in displaced or lost items or corruption of other data.


    Helsa wrote: »
    If you have a file of executable code, and no source code, then that is considered a black box. Even then technically it is not, because one could step through the assembler code, but um yeah . . . let's just call that a black box. If they have the source code though it is not, lack of proper documentation notwithstanding. It is a sad fact that even in the professional world, source code is usually not commented sufficiently, but that is par for the course. If you get a new software job, you will be handed something and have to figure it out, just like you did at all your previous jobs. Sure, it's a pain but you do it because that's what you're paid to do. For a new dev team facing insufficiently documented code made by a previous one, it will feel like a black box, at first for sure, but dev teams do more than conduct server merges. They have to fix bugs or add new features; they have to figure out the code. I understand your concern then that this could lead to missteps, while they ramp-up their familiarity with the code, but in this case, this merge does not require any editing of the game code. It is being accomplished strictly by editing fields in the database.

    The Q/A from the developers a number of years ago have explicitly named them as blackboxes and the reason why they were weary of doing updates to specific content. They may have since researched into them to remove their blackbox status, but it does not change the fact that any function with in the code that is poorly understood are called blackboxes. When working with databases, it is paramount to understand how the code interacts with the database. If an invalid entry is made it WILL lead to further issues. The fact is that money and man power is needed to research it, and how much money from the budget will be devoted to doing it. If you believe that editting a database outside of the program's normal operation does not involve the code, you will be in for a rude awakening if you apply that logic.
    Helsa wrote: »

    It's not a copy, it's an edit. Again there are no databases fused, it's all one database with objects having the values: Tarlach, Ruari, Mari, or Alexina, for their server fields. There are four active server objects of course, named after each of the servers; post merge there will be two. These objects will hold server wide relevant information such as guild stone placement, for example. Since guild stones spots are not going to survive this tells me they are making a new object called "Nao". "Nao" of course is likely to be the value contained in it's primary key, but that's fine as long as the objects that are supposed to be associated with it have "Nao" in their server field which of course would be one of their foreign keys. But here, the structure of the database remains the same you are just changing the values of the fields contained therein. Granted, if such fields fail to have their value changed to "Nao", where required post merge, then that will cause a break.

    If you have a copy of the database I would love to see it since I'm curious about how the data structures are organized. I can almost say for certain that the data structures are far more complex and entwined than you think they are and this goes far beyond just "editing" values. I can almost say for certain that databases will have to be merged given how much time and effort they put into this. If the issue was something simple like "editing" values, this would not be a big deal that took so long to do.


    At the end of the day I believe that you assume that the data structures and the merge are a simpe affair and that the merge itself is accomplished with the simple edits of just a few fields. As someone that deals extensively with databases on a daily basis, I can tell you for certain that there are matters that absolutely complicates this. Otherwise it wouldn't have taken them this long to even try something like this.
  • PanPan
    Mabinogi Rep: 3,745
    Posts: 418
    Member
    edited May 21, 2019
    Wdym. Transfering/merging data is as easy as copypasta.
  • HelsaHelsa
    Mabinogi Rep: 21,655
    Posts: 4,936
    Member
    GTCvActium wrote: »
    ...

    I think we're at the point of talking in circles, so I'll just summarize as best I can:
    - For me "Black Boxes" are files of executable code that have no corresponding source code and are only available during the linking portion of the build. If there is source code, it's not a Black Box, although it may be a challenge to work with.
    - I don't think this merge will require changes to the code, and will be accomplished strictly with database manipulation, specifically editing of fields. So any talk of Black Boxes, here I think, is irrelevant.
    - If I understood you correctly the work on the database for this undertaking will very likely involve more than simply editing server name fields, at least with respect to issues where server of residence must be known. I believe that they will literally just change every data instance of "Tarlach" "Ruari" and "Mari" to "Nao" and that understanding what is said in any Black Box, won't be necessary, at least with respect to issues where server of residence must be known.

    On these then, I think we're just going to disagree. I will grant you though, that should the merge actually go smoothly, I could not, in good conscience, consider that as proof of my position, as I recognize that it could be that you were right all along and that Nex-er-the-relevant-party-performing-the-merge either dodged a very big bullet or managed to be sufficiently diligent for this undertaking. I think perhaps we can both agree that issues arising from renaming objects such as characters and homesteads is high likely to be problematic.
  • CrimsọnCrimsọn
    Mabinogi Rep: 64,185
    Posts: 8,862
    Member
    Pan wrote: »
    Wdym. Transfering/merging data is as easy as copypasta.

    You really contradict yourself on these forums.

    DISCLAIMER: since the following post is not made by an employee of Nexon or any of it's affiliates or partners, what is contained therein is ultimately speculation. Until Nexon or any of its affiliates or partners has spoken definitively on the matters to be discussed, do not take them as granted, even if the language used happens to make it seem so.
    Wolfsinger