Provide migration instead of being backwards compatible

[SaWey]

I know this is quite a huge deal for Michiel and maybe for others, but I think it will be confusing when not changing the database at all.
Now that messages have become campaigns and users have become subscribers, it would make a lot of sense to change the naming in the database as well.
It will be confusing to put subscribers in the users database and do queries referencing user_ids etc.

I would even want to suggest another change, not to use mailing-lists anymore, but switch over to a more general filter system (so mailing lists can be compared to user attributes).
We can have categories of filters like:

• Mailing lists
  • News
  • Development
• Favorite color
  • Red
  • Green
    And use regular attributes as filters as well
• Name
• State
• Country
• ...

The GUI could easily split this up and still pretend like we use lists, but it might be easier to build a general filter for which subscribers need to receive a given campaign.

[tarekdj]

I'm totally ok with @SaWey . A cleaner database is a plus. And the migration process seems not very complicated imo.
@michield how can we force you to accept these changes? :-p

[michield]

Hmm, a migration process really burns the ships. But I guess if that makes it less complicated to work on it for new people, then yes, maybe.

I will think about it.

[tarekdj]

@michield and @SaWey! This is a blocker issue then we need a decision ASAP.

[michield]

I think that if this project concentrates on the core, and leaves the GUI to another project, that we need to keep the current structure. That way, we can use PL4 for "backend" stuff and keep PL3 for frontend stuff (for the time being) so that using PL3 and PL4 on the same database will be possible. However, the points made above are also valid.

So, I wonder whether we can use the DB abstraction to deal with the change. Using different table names is easy, but using different column names will be more complicated.

[tarekdj]

@SaWey are you OK if we implement the new terminology in a code level without changing database?
For eg. we can name a class Admin on code level and keep the SQL request deal with a table named "users". imo readable code matters more than a well named database. This way we can unblock this issue.

[michield]

Well, that's not a good example. Admins are not stored in the users table. But yes, readable code is also partly readable SQL which still would refer to old table names.

[SaWey]

@tarekdj That was kind of my "problem".
It's easy to change the class names, but it might be confusing when these classes are referencing tables with column names from the 'old' database.

@michield
I would rather choose to go with the old layout then to try and do this in the DB abstraction, as it might make it more complicated.

[michield]

@SaWey ok, so you agree to stay with old for now? I agree with the class vs table references, but I guess you also see my point? Tricky this. It might be good to code it in such a way that it is easy to switch. Once we have a V4-GUI we may want to do the migration.

[tarekdj]

@michield my example is not phpList related but just for demonstration.
@SaWey having a solid documentation can minimize the confusion

[michield]

@tarekdj +1 & +1

[SaWey]

Aggreed with Tarek.
Ok, I will close this issue/discussion with a final decision of using the old database and maybe migrate later on..