Migrations are creating duplicate Indexes

[adampatterson]

I didn't think that I made any changes to the table but when I hit save changes I chose to update the latest migrations and it's adding duplicates.

[TiagoSilvaPereira]

@adampatterson thanks for reporting, I'll check this

[adampatterson]

Not sure if this helps, but every time I tell it to save and add new I get copies of the same migrations.

[TiagoSilvaPereira]

@adampatterson does this happen if you create a new project and try to reproduce the same schema structure? If possible, could you please record a video so that I can reproduce this bug?

[adampatterson]

I'll give that a try tonight.

[adampatterson]

Creating a new app with the same structure seemed to work.

I took the migrations from the first app I made. Used Vemto to create a new project. Added the migrations, it asked to Sync. I said sure. I went to create the Filmanet resources, but didn't have any models. So I moved the models over, ran a sync.

Generated a Resource for each and it worked fine.

I made a couple of changes to the tables and they seemed to save and update OK.

I didn't run the app but the code generated without issue.

I know this is off topic for this issue, but how do you generate models from just the migrations? I think I clicked the play button.

It might be because I'm new to the app but I didn't realize that a dotted line in the ERD represented missing models.

I think overall the issues I had are solved but I don't know what combination of actions I did to get myself into those situations.

[TiagoSilvaPereira]

@adampatterson, you can add models to your tables in the Models section.

Migrations and models are both saved when you save schema changes (models are not generated when you hit the "Generate Code (F5)" button because models are synced with the code, so they need manual revision).

So basically, Vemto has two ways of generating code:

1—When you save schema changes, Vemto generates migrations and models (because those files need manual revision before the code generation to keep the schema synced with the code). This is similar to other code generation tools, like Genexus, etc. This Vemto feature can be used alone if you want to use it as a tool to edit your application Schema.

2 - When you hit the "Generate Code" Button, Vemto generates more specific application files, like CRUD views and components, factories, seeders, etc

I haven't had time to create Vemto 2 tutorials yet, but I have a 5 min video that illustrates well the steps to create a whole application with Vemto 2:

https://x.com/Tiago_Ferat/status/1758582516619817088

As it seems the issue was solved (probably because I made critical bug fixes on Vemto 2.0.15), I'm closing for now, but please feel free to open another issue report if necessary.

Best regards, Tiago

[adampatterson]

Thanks for the clarification.

I can really see the value in getting something up and running quickly here.

Have you used Vemto in your own projects long term?

I'm wondering how it handles external updates and then a modification made in Vemto.

For example I like to load my Filmanet Forms and tables from models via a trait.

Would Vemto get a conflic?

[TiagoSilvaPereira]

Hi, @adampatterson, this varies significantly according to how you use it. However, Vemto 1 was very different from Vemto 2 (it was only intended for the initial boilerplate). Since we are still in Alpha with Vemto 2, we are figuring things out as we develop.

Basically, Vemto 2 will be excellent for changing and generating new migrations and models. It is best for initial generation and minor tweaks for CRUD, filament panels, etc. As your code starts to grow, Vemto may produce conflicts. In this case, Vemto has some options to solve these problems:

1 - Move some parts of the code to Hooks (for example, you can view the Model's Hooks in the Table options and type extra code there) 2 - You can use the conflict resolution options that Vemto offers 3 - You can ask Vemto to ignore some files that you prefer to keep manually

What really sets Vemto 2 apart is its ability to read your project's current schema (tables and models). This way, you can keep it updated. This allows for things like:

1 - Add new tables and models to your project, even after months without using Vemto on it (something that was not possible in Vemto 1) 2 - Add new CRUD, Filament resources, API endpoints, etc 3 - Use it at any time when necessary. This doesn't mean that Vemto can understand all your code and can change it (this is only possible for migrations and models at the moment). However, it allows Vemto to continue generating boilerplates even for ongoing projects.

Some people ask me if it would be possible for Vemto to read the existing CRUD and change it. Unfortunately, this is impossible (at least not without an absurd investment of time and resources, as each project has particularities). So, I decided to focus on things that are well structured (models and migrations) and maintain the standard operation for the rest (views, cruds, panels, etc.), with some improvements such as conflict resolution, the possibility of ignoring specific files, etc.

[adampatterson]

Thanks for the detailed update!

I'll keep tinkering with the app. Even if it's not meant for long term complex apps I think there's enough value here in getting things off the ground quickly and a proof of concept in front of people with very little effort.

Cheers!