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

Pivotal ID # 184462975: Allow DB by pass even when not FIRE prefered source #682

Conversation

Juan-EBI
Copy link
Contributor

import java.io.File

/**
* Source that allows submitted to use store files directly in fire and bypass backend mechanism.
Copy link
Contributor

Choose a reason for hiding this comment

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

typo: "allows the submitter"

override val description: String
get() = "Provided Db files"

override fun getExtFile(path: String, dbFile: DbFile?, attributes: List<Attribute>): ExtFile? {
Copy link
Contributor

Choose a reason for hiding this comment

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

I understand this change and I think it makes sense, however, if we're to separate these type of files as yet another source, I think we should also decouple the responsability of passing around the DbFile but instead, treat this source like the others which are just a list of files, and populate it in the FilesSourceService

The reason why I'm suggesting this is because to me it doesn't make sense to create another type of list just to validate if a given parameter is of a given type but it should just give me the file. I think it actually makes more sense as it's right now since it gives us the understanding that there're are two types of fire files and we handle it all in the FireSource.

In summary, I think we should either leave it as it's or treat the DbFile as a separate type of files, properly populate it and refer to it just by path like in the other sources.

Sorry about the long message 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

great suggestion man, defenitly require way more changes but is the right way of desing and modeling this.

add(FilesListSource(files))
}

if (submitter.superuser) add(DbFilesSource)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is what I'm talking about, instead of just adding the object, we should add the list of any DbFiles present in the submission

Copy link
Contributor Author

Choose a reason for hiding this comment

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

but they can be a millions files, we by pass specifically for that reason

Copy link
Contributor

Choose a reason for hiding this comment

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

With your current implementation, we wouldn't need to have them all in memory but we would figure it out at runtime.

@@ -193,7 +195,7 @@ class ChangeLog007 {
@ChangeLog
class ChangeLog008 {
@ChangeSet(order = "008", id = "File List files index", author = "System")
fun changeSet007(template: MongockTemplate) {
fun changeSet008(template: MongockTemplate) {
Copy link
Contributor

Choose a reason for hiding this comment

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

hah! nice catch 👍


val result = testInstance.fileSequence(submission).toList()

assertThat(filesCount).isEqualTo(997)
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we use files.size() rather than a fixed number?

@@ -24,7 +24,8 @@ class FireFilesSource(
): ExtFile? {
return when (dbFile) {
null -> null
else -> fireClient.findByDb(dbFile, path, attributes)
is ConfiguredDbFile -> null
Copy link
Contributor

Choose a reason for hiding this comment

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

Following the thread above, we wouldn't really need this distinction since this source would only contain FIRE files and the other DbFiles (bypassed files)

target: OutputStream,
) {
val sourceFiles = serializationService.deserializeFileList(input, format)
.onEachIndexed { idx, bioFile -> logger.info { "$accNo, Mapping file $idx, path='${bioFile.path}'" } }
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice change, I wonder if we should apply the same validation to this endpoint so we don't have two separate validation workflows

…services into feature/pivotal-184462975-Allow-DB-by-pass-even-when-not-FIRE-prefered-source
Copy link
Contributor

@jhoanmanuelms jhoanmanuelms left a comment

Choose a reason for hiding this comment

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

LGTM. I like much better how it's looking now and kudos on the trick to figure out if the file should be bypassed on runtime 👍

override fun getFile(path: String): File? = null

@Suppress("ComplexCondition")
private fun getDbFile(attributes: Map<String, String?>): FireByPassFile? {
Copy link
Contributor

Choose a reason for hiding this comment

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

Clever implementation bro 🤓

add(FilesListSource(files))
}

if (submitter.superuser) add(DbFilesSource)
Copy link
Contributor

Choose a reason for hiding this comment

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

With your current implementation, we wouldn't need to have them all in memory but we would figure it out at runtime.

@Juan-EBI Juan-EBI merged commit 3befb1a into master Mar 1, 2023
@Juan-EBI Juan-EBI deleted the feature/pivotal-184462975-Allow-DB-by-pass-even-when-not-FIRE-prefered-source branch March 1, 2023 14:31
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