Skip to content
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

Open and parse files lazily #204

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

KeiichiHirobe
Copy link

@KeiichiHirobe KeiichiHirobe commented Jan 23, 2022

Current implementation always parse all of sql files, so may require a lot of time and memory if there are too many files or too big files in directory. But, in most of cases, we only need to parse 1~3 files because sort byId does not need content of files, it needs only the name of files.
So, I think it is better to parse sql files only when we need content of files.

Some migration sources are not supported to open/parse lazily in this PR.
HttpFileSystemMigrationSource,FileMigrationSource and EmbedFileSystemMigrationSource are supported, MemoryMigrationSource,AssetMigrationSource and PackrBox are not supported.

I don't think that's a problem because I guess most users don't use the latter migration sources.

I believe lazy loading should be the default behavior, but I made it optional with SetLazyLoad(true) to keep backward compatibility.

ref: #203

migrate.go Outdated
Comment on lines 124 to 144
type Migration struct {
Id string
Up []string
Down []string

type MigrationData struct {
Up []string
Down []string
DisableTransactionUp bool
DisableTransactionDown bool
}

type migrationFile struct {
dir http.FileSystem
root string
baseName string
}

type Migration struct {
Id string

// data may be nil if not parsed yet.
data *MigrationData
// file is information of migration file, which is used to parse later.
// file may be nil if migration file has already been parsed when Migration is initialized.
file *migrationFile
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a problem really. It changes the external API of the library, which means it may break peoples code. And I'd rather not do that.

Unless we find a way to do this without breaking the API, I'm afraid this won't be an option.

Copy link
Author

@KeiichiHirobe KeiichiHirobe Feb 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rubenv
I am very sorry, I did not notice sql-migrate is used not only as a standalone tool but also as a library.
I reverted 859f73b, and submitted a new commit 14223b2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants