-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let TomApplication accept a parent/delegator migration class #47
Comments
Hi, I understand what you mean and why you would want to have something like this, but it's not possible as all migrations logic counts with migrations to be in separate files, the reason is that migrations also contain timestamps and they must be migrated in the specific order, it could be possible to do it like that but it would be a lot of work. |
The order is decided by these timestamps in the migrations' filenames. |
Also, there is a It generates a filename like This bug was already fixed in the |
I have a little time now and am still thinking about this. There is a reason why seeders have this feature and that is we can group and categorize seeders and then apply them based on the environment, so you can use different seeders for staging, testing, or development areas, or even invoke different seeders in unit tests before testing some feature. But this isn't true for migrations, there is nothing like I will have different columns or tables based on env., all environments will use the same migrations. I think this is the reason why I designed it this way. Can you explain why you would need this for migration as well? Thx |
In our software we have different dlls. Two of these are "core" and "project". "Core" contains functionality that our very basic application consists of, in later stages we port back functionality from project that we deem usefull in further projects . "Project" contains project specific functionality for the current customer project. This includes database adaptions and many other things. Since we strictly seperate our core code from project code, we gain the benefit of "simply deleting" the project source code and we start with a fresh core application, ready for the next customer. With the current implementation of tinyorm we have to make adjustments in our core for project database adjuments. It's not very clean and easy to look over. I've seen this practice a lot in the industry, thats why we also decided to do it like this. Could be, that I'm the only one in need for this. |
Whether you would use this functionality in the core or project sources is unclear, but it doesn't matter. I understand what you want to achieve. The solution is simple for you, you can create your own base Now I looked at it and it's not a good idea, it wouldn't work, migrations have up/down virtual methods and it looks like it will not even be possible to do it this way. The problem is that I don't remember how these migrations are implemented behind the scenes 😁, so I'm not able to propose another solution. It's 2 years ago when I coded it and that's a long time to remember implementation details. 🤯 I'm not going to implement it because it's non-standard. Sry 😞 |
Hi,
with seeders its possible to go
Which contains following code in my project
As you can see, with this approach I am able to seed project specific data and at the same time keep my core data which will always provided nicely seperated.
Can the same be implemented for the
.migration<>
part of TomApplication?Right now I got this
But would like to have something like this
Which follows same principle as the seeder
The text was updated successfully, but these errors were encountered: