script based FileMigrationLoader #112
Comments
|
Thank you for the idea, @chb0github ! To all, |
Your reply also didn't address any of my points:
|
|
What do you achieve from having this in migrations core vs just adding it as your own I'm never in favor of complicating especially when it's just to support one off style processes. |
|
I am not working with a Java-based migration project. If I have to implement a This approach actually would allow migrations to essentially end the one-off requests. Migrations greatest features are it's commendable flexibility; it doesn't get any better than this. I think the part that seems to be missing is that: Not all projects using migrations are java based and opening it up to not requiring Java dev skills is really unique and gives migrations an edge against the competition. Frankly, it's a killer feature IMO that can be implemented fairly straightforwardly. I am a seasoned vet - I'm not proposing some hack and of course, code review it. If it's a matter of support, then I will continue to support it even after release. Though again, it's going to be a pretty easy implementation so I don't imagine there should be any issues. I am trying to be a positive contributor and I think this is a feature that will generate many stars. Thanks for considering. |
|
@h3adache I am having trouble seeing where this is 'one-off', when you acknowledge there are not only a few people asking for similar features, but offering to have their implementations form the foundation of the features themselves. This feature addresses a legitimate pain with the use of mybatis, namely it needs to be included within a Java based project. The functionality of the tool is excellent, and the applicability of the script based non-annotated invocation of the functionality could be very wide within the software development field. The benefit to describing rejection of this feature as a simplification is dubious, as it is implemented with interfaces in order to allow this type of extension to be modularized, and independent. @harawata If @chb0github would like to contribute the documentation fixes as well, this should leave your 2) as your only concern. In which case I would refer to my point above, how does this complicate the implementation at all? The only concern I can see is if this parser could in some way introduce a security vulnerability through the scripting interface. |
|
This would essentially open up mybatis to the entire LAMP stack universe; I'm failing to see the downside.. |
|
@hibaymj @litwicki I appreciate the enthusiasm. But I fail to see how it's currently NOT opened up to those other stacks. I use it myself in many non java/jvm projects (js, perl, python, c++). @hibaymj again, appreciate the feedback but I said directory based loading was what was requested multiple times and that is now handled by @harawata's commit and can be a drop in plugin to migrations. Please read what was written before attacking me. |
|
@h3adache - in a C++ project: Do you have a custom Last I heard @harawata hadn't merged in those changes yet. And, that's handy. He actually opened it up to support his use case. Kudos. |
|
@h3adache Apologies for the apparently heavy handed response, no attack was initiated or intended. I had to spend the previous 5 hours doing HR related training, nerves were a bit raw apparently. What I believe @chb0github is saying is that migrations assumes there is a Java build tool being used to build the project, which is clearly not the case when using NPM, Yarn, Phing, Deployer, etc... You would still have the dependency of a JVM in the environment to execute migrations, however you wouldn't be required to use a Java based build tool for your project to build the custom project loader. This is the limitation I believe this issue is attempting to address. Do the hooks you referenced by @harawata address this concern and allow this flexibility? |
|
@chb0github We try to be deliberate in choosing what to add (e.g. Does it benefit many users? Is it within the scope of the project?, etc.) because, while adding a new feature/option is relatively easy and can be done at any time, it’s quite difficult to remove it once it’s published and it has to be maintained. It is understandable that you feel frustrated to see your idea/PR/request is rejected and it may be our fault if our explanation is not satisfactory. |
|
@hibaymj turned me on to your project a couple of months ago and I asked
him what he thought of this idea. His words are his own and I didn't put
him up to this at all.
I am working with one other person and he is watching the several issues I
have open as it effects him to.
The fact remains that I am not working with a Java project and the other
people who will work with the project when I am done know nothing about
compiling or deploying Java. To use a custom `FileMigrationLoader` would
require a Java project and build and the subsequent jar placed in the
project classpath. Infact, the entire company I work at is mostly
unfamiliar with Java.
I recommended this feature because I believe it really opens up
possibilities with distinctive functionality that no other migration tool
has.
When I was evaluating tools for db migrations any that were code only
approaches I had to reject because the users of the project are dbas.
1. So it had to have strong SQL support.
2. It also had to have rollback functionality
3. It needed to have pre and post validate and this is where hooks prove
handy
4. For reasons too baffling even for me to explain, we have 1 app sitting
on anywhere between 1 and 3 databases depending on where it's deployed;
with schema and tables split arbitrarily between them. WTF?! You say? This
is where the custom migration loaders save the day. However, they currently
require being written in Java; see above.
I am sorry the commentary has gotten out of hand and you should make the
decision best for your user base. I do politely ask that you continue to
evaluate it based on merits.
Nothing but respect for all of your efforts and keep up the good work.
…On Tue, Jan 2, 2018, 10:24 PM Iwao AVE! ***@***.***> wrote:
@chb0github <https://github.com/chb0github>
I have to assume that you asked your friends (who obviously do not
understand the purpose of this request correctly) to vote this issue up to
force us to accept your contribution.
It makes it difficult for us to evaluate what really is beneficial to this
project and also is disrespectful to users who actually use this tool.
More than anything, it makes me really disappointed to see a respected
developer like you do such a thing.
We try to be deliberate in choosing what to add (e.g. Does it benefit to
many users? Is it within the scope of the project?, etc.) because, while
adding a new feature/option is relatively easy and can be done at any time,
it’s quite difficult to remove it once it’s published and it has to be
maintained.
If you are not familiar with this idea, here are a few good reads.
https://lord.io/blog/2014/oss-tips/
https://opensource.guide/best-practices/#learning-to-say-no
It is understandable that you feel frustrated to see your idea/PR/request
is rejected and it may be our fault if our explanation is not satisfactory.
But we committers are trying to do what is best for the project and if you
cannot believe it, you would have to create a new project of your own.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaI0KtFZLZuE7BaeLz_mhaW1EsOMRIVks5tGx0LgaJpZM4RP99o>
.
|
|
Count me as uninformed. This is for my learning benefit. How exactly do you even end up using something written in java even if just an interface without actually using the jvm? It's still byte code at that point. I also fail to see how other tools could not be used with underlying users needing to learn java. I don't think they need too. There is a maven wrapper. You can plug in frontend maven plugin and it will handle many things like yarn. So at best a maven execution is all someone might need without knowing what that does. Really for my own benefit as a dev/ops guy trying to understand that piece and how it would work. A sample demo would be nice to look at. My shop is 50/50 java and . Net so this understanding might be very useful to me.
I'm also going to see if I can get a dba guru I work with to look at all this.
I think to everyone else's broader point it's a lot of extra code we end up having to learn support and otherwise. If you could build on your own project as many do that with mybatis then release to central you will start getting monthly sonatype statistics. A link from us is much easier to support initially and let's say for argument sake that 1000 people with individual ip addresses download you project a month and it grows. That would turn the tides I believe. But on the other hand what if it's only you using it, it gets no forks, no stars, etc. And there I think lies the concern.
Keep in mind I'm really dev/ops in this regard so I cannot make a true informed decision on the existing code base let alone new logic. I just know it's big and that always raised concerns. And it's certainly a balancing act as no one ever wants to scare away contributors. I work many projects were everyone else left and it's really tough. Mybatis has a huge group of great people and I find it extremely rare that is the case so I trust each and everyone on the team and what they have to say either way. I know many on the team have side mybatis things that are not with the team and sometimes a few years go by before those land with the team. I think that goes to the statistics gathering where there might otherwise be concern.
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Christian Bongiorno <notifications@github.com>
Sent: Wednesday, January 3, 2018 2:31:15 AM
To: mybatis/migrations
Cc: Subscribed
Subject: Re: [mybatis/migrations] script based FileMigrationLoader (#112)
@hibaymj turned me on to your project a couple of months ago and I asked
him what he thought of this idea. His words are his own and I didn't put
him up to this at all.
I am working with one other person and he is watching the several issues I
have open as it effects him to.
The fact remains that I am not working with a Java project and the other
people who will work with the project when I am done know nothing about
compiling or deploying Java. To use a custom `FileMigrationLoader` would
require a Java project and build and the subsequent jar placed in the
project classpath. Infact, the entire company I work at is mostly
unfamiliar with Java.
I recommended this feature because I believe it really opens up
possibilities with distinctive functionality that no other migration tool
has.
When I was evaluating tools for db migrations any that were code only
approaches I had to reject because the users of the project are dbas.
1. So it had to have strong SQL support.
2. It also had to have rollback functionality
3. It needed to have pre and post validate and this is where hooks prove
handy
4. For reasons too baffling even for me to explain, we have 1 app sitting
on anywhere between 1 and 3 databases depending on where it's deployed;
with schema and tables split arbitrarily between them. WTF?! You say? This
is where the custom migration loaders save the day. However, they currently
require being written in Java; see above.
I am sorry the commentary has gotten out of hand and you should make the
decision best for your user base. I do politely ask that you continue to
evaluate it based on merits.
Nothing but respect for all of your efforts and keep up the good work.
On Tue, Jan 2, 2018, 10:24 PM Iwao AVE! ***@***.***> wrote:
@chb0github <https://github.com/chb0github>
I have to assume that you asked your friends (who obviously do not
understand the purpose of this request correctly) to vote this issue up to
force us to accept your contribution.
It makes it difficult for us to evaluate what really is beneficial to this
project and also is disrespectful to users who actually use this tool.
More than anything, it makes me really disappointed to see a respected
developer like you do such a thing.
We try to be deliberate in choosing what to add (e.g. Does it benefit to
many users? Is it within the scope of the project?, etc.) because, while
adding a new feature/option is relatively easy and can be done at any time,
it’s quite difficult to remove it once it’s published and it has to be
maintained.
If you are not familiar with this idea, here are a few good reads.
https://lord.io/blog/2014/oss-tips/
https://opensource.guide/best-practices/#learning-to-say-no
It is understandable that you feel frustrated to see your idea/PR/request
is rejected and it may be our fault if our explanation is not satisfactory.
But we committers are trying to do what is best for the project and if you
cannot believe it, you would have to create a new project of your own.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABaI0KtFZLZuE7BaeLz_mhaW1EsOMRIVks5tGx0LgaJpZM4RP99o>
.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#112 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AA7ho3swsIoXEkHNajOB-3LB9EXRp4Tzks5tGyzDgaJpZM4RP99o>.
|
|
@hazendaz - Hey Jeremy, That's a fantastic question and my issue really is directed toward the operational aspect of managing minor changes. The distinction is this:
What I am proposing is not "a whole lot of extra code" - Honestly, the implementation might amount to 40-60 lines in a single source file. Also, Java has something called interfaces - software contract that are designed to isolate varying implementations of the same basic concept. They are a bedrock of modern object oriented programming and I am proposing to implement one that eliminates the need for a jdk; you can never get rid of the jre (and this is crucial). As a devops guys this actually effects you most. Which would you prefer:
alternately
I am proposing writing 50 lines of code to eliminate 8 operational steps and all the associated permission issues. Permanently if the user chooses to. And, I can do it entirely isolated and backward compatibly. This change is not at all invasive and leveraged existing code to it's fullest Jeremy: You, as a total non-java guy, could make necessary changes if needed. Mostly people can work their way through script files To the rest of the migrations team: I understand your concern: You don't want to be implementing and folding in every permutation of someones latest idea. 100% on board. Part of the reason people walk away from a tool/project and using it is because of maintenance. And so they essentially propose the change so that it can be folded into the maintenance process already in place. If you accept this change, no user going forward will have any case to make for a new implementation being hosted by you guys because they can just use scripts on their end, check them in and have no extra build requirements. |
|
I have production ready code. If a PR is going to be reviewed and potentially accepted I will create one - in addition I will supply a sample project that this approach helps address |
The
MigrationLoaderand theFileMigrationLoaderFactorymake things really flexible. But, I would like to propose another implementation that will really open up mybatis to non-java developers and allow for a light-touchSome background:
The situation I am trying to address requires a custom
MigrationLoader. And, it seems to be working the way I would like it to be. But, let's consider what I will need to do to take advantage of itdriversdirectory since I know this will get picked up on the class path. Should I create a custommigrationsscript to check to see if it has the latest migration loader I wrote before running and download it if needed (including getting around any security issues I might encounter while checking with the artifact repo)? Or, should I just check in the jar into the migration project underdriversand update as needed?The question thus arises: Where should I put this Java project that consists entirely of 2 java files and 1 meta file?
Should I:
Option 1is really a heavy weight process to get about 40 lines of code in useOption 2is bound to really confuse people who are totally unfamiliar with java.It would really open up migrations to non-java developers (or java developers where a heavy touch process is not desired). We could use the existing scripting configuration/functionality.
I am willing to make the changes and make sure they are backward compatible. I would just like to donate it to the community because I think it would allow for a very light foot-print when customizing and because it would be a stand-out feature from all the other migration tools.
The text was updated successfully, but these errors were encountered: