Move setup and upgrade to migration model

[tmccormi]

Laravel has a process called 'artisan migrate' - https://laravel.com/docs/5.2/migrations

Not sure if we can use it directly, but we should use this model for data setup and database upgrades.

[teryhill]

I think we need to bring this up again. I have some table changes and I need to know how we are going to do upgrades to the database

[tmccormi]

Yes. Now that we have an official release that is intended for end users we need a patch and update model. What OpenEMR had is not bad, but it's not granular and it's easy to break.

@kchapple has been using a hybrid that looks like this:

Migration_2017_02_02_09_46_10.php - that is date stamped versus "bulk" versioned

it requires... use \Framework\Plugin\Migration\Migration; and Inside it uses the same #IfMissingColumn / #EndIF structure but wraps it in a class function_up() {..} Laravel style.

an additional class function_down() {..} is used to revert a migration action set

[tmccormi]

@growlingflea can you take this one on please?

[aethelwulffe]

With extra butter and cheese on top?

[aethelwulffe]

This is directed at a file-per-table dealio, ja? Is there going to be a "check whole table structure, output a diff, then ask to run structure table or insert" kind of thing keeping separated structure and insert files and all that, or... Seems like a function that parses all files or directories and then compares might be better than a versioning system...but I am just making some noise. I will say that having a pretty elaborate /sql directory and a slick little structural iterator script has been a maintenance boon for us on another project.

[teryhill]

@tmccormi any word from Dan on this. If he is busy I would suggest for the time being we go back and resurrect the old way of doing it.

[chandimajayawickrama]

I would like to work on this issue.

[teryhill]

@tmccormi or @aethelwulffe can you set @eran13com as the assignee on this

[aethelwulffe]

DO IT WhoooHooo!

On 2017-07-19 09:37, Chandima Jayawickrama wrote:

I would like to work on this issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LibreHealthIO/LibreEHR/issues/91#issuecomment-316390158, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhzF3FO9wltGvw3U2SGW2bxg82Ulj8_ks5sPga1gaJpZM4Jk6N_.

[aethelwulffe]

@eran13com I need you to accept the collaboration invite at https://github.com/LibreHealthIO/LibreEHR/invitations before we can "officially" assign you to an issue. I will re-send the invitation email.

[chandimajayawickrama]

@aethelwulffe I did accept the collaboration invite. :)

[teryhill]

@eran13com You have been assigned to this . Have fun and let us know when you need some help.

[chandimajayawickrama]

@teryhill thanks. Yeah sure I will let you know. :)

[tmccormi]

Setup process should definitely create the equivalent to the sqlconf.php file rather than this being part of a template in the repo.

The environment should be created "outside" of the source code installation for security as well as the (eventual) ability to containerize the code

[chandimajayawickrama]

I am working on database migration part. Currently I am creating the schema for database tables and views for the UI. I am very sorry for such a long period of silence, I was a little busy with exams and stuff.

[teryhill]

No problem @eran13com . We understand busy with school. When you get a chance show us where your thought process is going, What is your vision for this?

[chandimajayawickrama]

Thank you @teryhill. :) I will let you know for sure.

[chandimajayawickrama]

@teryhill I think it will be better to create the database migrations for each table in separate files, won't it? That way it will be easier to modify and debug easily than putting up the whole database table migration in one file. Please let me know your ideas about it. :)

[Trodrige]

@eran13com if I'm getting it clearly, you mean the same like in Laravel. If yes, then I think it'll be better that way.

[aethelwulffe]

Yes, Look at #599 Team up. @pri2si17-1997 Priyanshu has made huge progress in this direction, and he is good to work with. LOTS of work done in this direction already, and I bet as a collaboration, this would be a lot more fun for Pri too.

[teryhill]

@eran13com Yes multiple files is the correct approach. I agree with @aethelwulffe you should form a team with @pri2si17-1997 and @Trodrige

[chandimajayawickrama]

Yes @Trodrige just like in Laravel. Of course @teryhill and @aethelwulffe I will team up with @pri2si17-1997 and @Trodrige . :)

[pri2si17-1997]

Yes @aethelwulffe @teryhill .. I am ready to team up with @eran13com @Trodrige .. :slightly_smiling_face: As pointed above, migrations for almost all tables are generated.. We can start working on view and make the necessary changes/improvements in migrations. But we need to discuss once. :slightly_smiling_face:

[chandimajayawickrama]

@pri2si17-1997 may we all commit to the same branch? Me, you and @Trodrige all. Then it will be easy. Please let me know. :)

[chandimajayawickrama]

And yeah, since need to discuss with our mentors, let us arrange and discuss :)

[pri2si17-1997]

Yes @eran13com @Trodrige . I got busy with my school stuff so I was not able to reply. I will post my view on forum where we all can discuss and get inputs. :slightly_smiling_face:

Regarding "committing on same branch" means? Every clone repository has its local branch but when we push commits to the same branch then there will be unnecessary complexity of re-basing. You make your changes and raise PR. Not sure I answered your question or not. Please ask if any doubts... :slightly_smiling_face:

[aethelwulffe]

I have a better idea. We create a base feature branch here for the project, create a a "project" here to handle that, and you guys handle merging to that branch until it is time to merge into master. Ja? We need to ensure that everyone has the appropriate write permissions, and everyone has joined the project as a collaborator. Note: We are creating the "Gee-Sock!" release, which is a "fix everything you can this week, cause it launches on October 15 no matter what" release before the GCI meeting. This release showcases the GSOC contributions, and frankly the contributions of our new developers over the whole of the last year. This is clearly deserving of a 2.0 level release, and will be so, with clear credit to the developers.

We are pushing hard for another MAJOR release...something with a refactored data schema, or at least a major data migration model. We STRONGLY suggest to you guys that you look up and investigate the FHIR API. This is a data schema that serves as the translation interoperability point between medical data systems. That is VERY IMPORTANT. LibreHealth EHR must have a very aware FHIR API implementation. It would be even better to start moving the LHEHR data schema towards that of the FHIR API. So, in addition to the fact that learning the FHIR API is a very valuable training project to anyone working in this field for the next couple of decades; in addition to the fact that having an FHIR implementation at a grass-roots stage of FHIR adoption is a heck of a nice...even pivotal item for a resume, I also think that since it is a better schema than we have already, it might actually make this process easier.

Note: Look through the LibrehealthIO repositories for the FHIR api/server repos as a possible starting point for some of this stuff. These were not built directly by the community, but I imagine that they could be leveraged.

[tmccormi]

As long as they are working on their own gitrepo replica, then it's not a problem. I just won't merge non-release pull requests into master until I create the rel_200 branch.

Tony McCormick, CTO www.mi-squared.com Support: 866-735-0897, Direct: 713-574-6709 My Calendar: http://bit.ly/XznvDo -Verba volant, scripta manent

On Thu, Sep 28, 2017 at 10:28 AM, Art Eaton notifications@github.com wrote:

I have a better idea. We create a base feature branch here for the project, create a a "project" here to handle that, and you guys handle merging to that branch until it is time to merge into master. Ja? We need to ensure that everyone has the appropriate write permissions, and everyone has joined the project as a collaborator. Note: We are creating the "Gee-Sock!" release, which is a "fix everything you can this week, cause it launches on October 15 no matter what" release before the GCI meeting. This release showcases the GSOC contributions, and frankly the contributions of our new developers over the whole of the last year. This is clearly deserving of a 2.0 level release, and will be so, with clear credit to the developers.

We are pushing hard for another MAJOR release...something with a refactored data schema, or at least a major data migration model. We STRONGLY suggest to you guys that you look up and investigate the FHIR API. This is a data schema that serves as the translation interoperability point between medical data systems. That is VERY IMPORTANT. LibreHealth EHR must have a very aware FHIR API implementation. It would be even better to start moving the LHEHR data schema towards that of the FHIR API. So, in addition to the fact that learning the FHIR API is a very valuable training project to anyone working in this field for the next couple of decades; in addition to the fact that having an FHIR implementation at a grass-roots stage of FHIR adoption is a heck of a nice...even pivotal item for a resume, I also think that since it is a better schema than we have already, it might actually make this process easier.

Note: Look through the LibrehealthIO repositories for the FHIR api/server repos as a possible starting point for some of this stuff. These were not built directly by the community, but I imagine that they could be leveraged.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LibreHealthIO/LibreEHR/issues/91#issuecomment-332907315, or mute the thread https://github.com/notifications/unsubscribe-auth/AARci3-SSoS8y1FpsL5Ezn61BG9rZQD7ks5sm9c1gaJpZM4Jk6N_ .

-- Please be aware that e-mail communication can be intercepted in transmission or misdirected. Please consider communicating any sensitive information by telephone. The information contained in this message may be privileged and confidential. If you are NOT the intended recipient, please notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and destroy this message.

[aethelwulffe]

We have a PR against this from a new person:

923

I have not gone through all of it yet myself, hoping he may give us a little background.

[aethelwulffe]

Suggesting that this get merged into a setup tracking project.