Force Artifactory to use numerical comparison when searching?When maven says “resolution will not be reattempted until the update interval of MyRepo has elapsed”, where is that interval specified?how to generate metadata for RPM repository in ArtifactoryHow to configure settings.xml to pull from Artifactory private virtual repository?Gradle publish attemps to upload RPM to Artifactory YUM repo twice, second time fails with 403Artifactory REST API Latest Release VersionHow to get specific property value in ArtifactoryArtifactory - What is the limit on number of artifact properties or values and its performance impactHow to download the artifactory by parsing AQL using curl script?How to get artifact file's URI using Artifactory's checksum API where multiple artifacts have same SHA-1 / SHA-256 values aka file's contenthow to change the include section of an AQL query in a file spec

Does a Hand Crossbow with the Repeating Shot Infusion still require a Free Hand to use?

for xml path('') output

Most elegant way to write a one-shot 'if'

Should 私の be omitted?

The warming up game

Find the radius of the hoop.

Which is better for keeping data: primary partition or logical partition?

What verb for taking advantage fits in "I don't want to ________ on the friendship"?

Movie with Zoltar in a trailer park named Paradise and a boy playing a video game then being recruited by aliens to fight in space

How can I deal with extreme temperatures in a hotel room?

What's the safest way to inform a new user of their password on an invite-only website?

Can a stressful Wish's Strength reduction be cured early by a Greater Restoration spell?

What is "oversubscription" in Networking?

How did they film the Invisible Man being invisible, in 1933?

I just started should I accept a farewell lunch for a coworker I don't know?

How to securely dispose of a smartphone?

Is it possible to have a character with proficiency in all martial weapons without proficiency in Medium armor?

Different budgets within roommate group

How did Lefschetz do mathematics without hands?

Sharing referee/AE report online to point out a grievous error in refereeing

Using “ser” without "un/una"?

Bad guy wins in my book series

How do I ensure my employees don't abuse my flexible work hours policy?

Thin wall to block LED light from hitting photodiode?



Force Artifactory to use numerical comparison when searching?


When maven says “resolution will not be reattempted until the update interval of MyRepo has elapsed”, where is that interval specified?how to generate metadata for RPM repository in ArtifactoryHow to configure settings.xml to pull from Artifactory private virtual repository?Gradle publish attemps to upload RPM to Artifactory YUM repo twice, second time fails with 403Artifactory REST API Latest Release VersionHow to get specific property value in ArtifactoryArtifactory - What is the limit on number of artifact properties or values and its performance impactHow to download the artifactory by parsing AQL using curl script?How to get artifact file's URI using Artifactory's checksum API where multiple artifacts have same SHA-1 / SHA-256 values aka file's contenthow to change the include section of an AQL query in a file spec






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















I am trying to find the latest (or earliest, depending on comparison operator) version of an RPM package (the RPM bit is important). I am using AQL query similar to this one:



items.find( 
"$and" : [
"@rpm.metadata.name": "$eq": "awesome_package",
"@rpm.metadata.version": "$gte": "19.300.0.58" ]
)
.include("@rpm.metadata.version")
.sort( "$asc": [ "name" ])


As already answered by Artifactory KnowledgeBase, it's impossible to sort on properties, so instead of just sorting on @rpm.metadata.version and taking the first top result by using .limit(1) I must use property condition in the find clause.



It appears though that Artifactory's built-in comparison is purely lexicographic, so for the query above I get the following result:




"results" : [
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.9-1.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.9"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.58-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.58"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.59-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.59"
]
],
"range" :
"start_pos" : 0,
"end_pos" : 3,
"total" : 3




This result includes version 19.300.0.9, which, according to RPM spec, is older than what I am searching for (>= 19.300.0.58) and shouldn't be included in the results, but Artifactory finds it nonetheless, most likely due to its search comparisons being lexicographic.



Also note the ordering of the results, which does appear to use numerical sorting (version "19.300.0.9" comes before "19.300.0.58" and "19.300.0.59").



Question: is it possible to force Artifactory to use numerical (SemVer) comparison in search criteria? If not, is there any other way I can exclude irrelevant versions from the result list?










share|improve this question






















  • .include("@rpm.metadata.version") .sort( "$asc": [ "name" ]) -- You have sorted the result in asc order with name field. Is this the earliest version greater than equal to19.300.0.58 ?

    – error404
    Mar 25 at 15:47











  • @error404: yes, I have sorted on the name field b/c sorting on properties (e.g. @rpm.metadata.version) is not supported. As a matter of fact, sort clause is irrelevant here: my main problem is that I have expected to get only two matches in the result (.58 and .59), but I am also getting a (much earlier) .9.

    – KMZ
    Mar 26 at 9:00











  • I feel the result is proper the version of the awesome_package-19.300.0.9-1.noarch.rpm would be higher than the previous one as this one ends with -1 instead of -0. If it would have been -0 then the result should not be part of the aql

    – error404
    Mar 26 at 9:54











  • @error404: -1 is in fact a property called @rpm.metadata.release, and is not related to @rpm.metadata.version property I use when searching. Artifactory correctly parses EVR (epoch/version/release) for deployed artifacts: if I search for artifacts using items.find( "$and" : [ "@rpm.metadata.name": "$eq": "awesome_package", "@rpm.metadata.version": "$eq": "19.300.0.9" ] ) I only get one result (as expected). It's just that $gte comparison treats version as a string, ignoring RPM spec that lays out (different) comparison semantics.

    – KMZ
    Mar 26 at 17:02







  • 1





    ok, I have not used the rpm so was not aware of the properties used. Can't you use created_by field to get the latest version ?

    – error404
    Mar 28 at 9:05

















1















I am trying to find the latest (or earliest, depending on comparison operator) version of an RPM package (the RPM bit is important). I am using AQL query similar to this one:



items.find( 
"$and" : [
"@rpm.metadata.name": "$eq": "awesome_package",
"@rpm.metadata.version": "$gte": "19.300.0.58" ]
)
.include("@rpm.metadata.version")
.sort( "$asc": [ "name" ])


As already answered by Artifactory KnowledgeBase, it's impossible to sort on properties, so instead of just sorting on @rpm.metadata.version and taking the first top result by using .limit(1) I must use property condition in the find clause.



It appears though that Artifactory's built-in comparison is purely lexicographic, so for the query above I get the following result:




"results" : [
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.9-1.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.9"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.58-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.58"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.59-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.59"
]
],
"range" :
"start_pos" : 0,
"end_pos" : 3,
"total" : 3




This result includes version 19.300.0.9, which, according to RPM spec, is older than what I am searching for (>= 19.300.0.58) and shouldn't be included in the results, but Artifactory finds it nonetheless, most likely due to its search comparisons being lexicographic.



Also note the ordering of the results, which does appear to use numerical sorting (version "19.300.0.9" comes before "19.300.0.58" and "19.300.0.59").



Question: is it possible to force Artifactory to use numerical (SemVer) comparison in search criteria? If not, is there any other way I can exclude irrelevant versions from the result list?










share|improve this question






















  • .include("@rpm.metadata.version") .sort( "$asc": [ "name" ]) -- You have sorted the result in asc order with name field. Is this the earliest version greater than equal to19.300.0.58 ?

    – error404
    Mar 25 at 15:47











  • @error404: yes, I have sorted on the name field b/c sorting on properties (e.g. @rpm.metadata.version) is not supported. As a matter of fact, sort clause is irrelevant here: my main problem is that I have expected to get only two matches in the result (.58 and .59), but I am also getting a (much earlier) .9.

    – KMZ
    Mar 26 at 9:00











  • I feel the result is proper the version of the awesome_package-19.300.0.9-1.noarch.rpm would be higher than the previous one as this one ends with -1 instead of -0. If it would have been -0 then the result should not be part of the aql

    – error404
    Mar 26 at 9:54











  • @error404: -1 is in fact a property called @rpm.metadata.release, and is not related to @rpm.metadata.version property I use when searching. Artifactory correctly parses EVR (epoch/version/release) for deployed artifacts: if I search for artifacts using items.find( "$and" : [ "@rpm.metadata.name": "$eq": "awesome_package", "@rpm.metadata.version": "$eq": "19.300.0.9" ] ) I only get one result (as expected). It's just that $gte comparison treats version as a string, ignoring RPM spec that lays out (different) comparison semantics.

    – KMZ
    Mar 26 at 17:02







  • 1





    ok, I have not used the rpm so was not aware of the properties used. Can't you use created_by field to get the latest version ?

    – error404
    Mar 28 at 9:05













1












1








1








I am trying to find the latest (or earliest, depending on comparison operator) version of an RPM package (the RPM bit is important). I am using AQL query similar to this one:



items.find( 
"$and" : [
"@rpm.metadata.name": "$eq": "awesome_package",
"@rpm.metadata.version": "$gte": "19.300.0.58" ]
)
.include("@rpm.metadata.version")
.sort( "$asc": [ "name" ])


As already answered by Artifactory KnowledgeBase, it's impossible to sort on properties, so instead of just sorting on @rpm.metadata.version and taking the first top result by using .limit(1) I must use property condition in the find clause.



It appears though that Artifactory's built-in comparison is purely lexicographic, so for the query above I get the following result:




"results" : [
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.9-1.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.9"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.58-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.58"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.59-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.59"
]
],
"range" :
"start_pos" : 0,
"end_pos" : 3,
"total" : 3




This result includes version 19.300.0.9, which, according to RPM spec, is older than what I am searching for (>= 19.300.0.58) and shouldn't be included in the results, but Artifactory finds it nonetheless, most likely due to its search comparisons being lexicographic.



Also note the ordering of the results, which does appear to use numerical sorting (version "19.300.0.9" comes before "19.300.0.58" and "19.300.0.59").



Question: is it possible to force Artifactory to use numerical (SemVer) comparison in search criteria? If not, is there any other way I can exclude irrelevant versions from the result list?










share|improve this question














I am trying to find the latest (or earliest, depending on comparison operator) version of an RPM package (the RPM bit is important). I am using AQL query similar to this one:



items.find( 
"$and" : [
"@rpm.metadata.name": "$eq": "awesome_package",
"@rpm.metadata.version": "$gte": "19.300.0.58" ]
)
.include("@rpm.metadata.version")
.sort( "$asc": [ "name" ])


As already answered by Artifactory KnowledgeBase, it's impossible to sort on properties, so instead of just sorting on @rpm.metadata.version and taking the first top result by using .limit(1) I must use property condition in the find clause.



It appears though that Artifactory's built-in comparison is purely lexicographic, so for the query above I get the following result:




"results" : [
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.9-1.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.9"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.58-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.58"
]
,
"repo" : "yum-private-local",
"path" : "some/path",
"name" : "awesome_package-19.300.0.59-0.noarch.rpm",
"properties" : [
"key" : "rpm.metadata.version",
"value" : "19.300.0.59"
]
],
"range" :
"start_pos" : 0,
"end_pos" : 3,
"total" : 3




This result includes version 19.300.0.9, which, according to RPM spec, is older than what I am searching for (>= 19.300.0.58) and shouldn't be included in the results, but Artifactory finds it nonetheless, most likely due to its search comparisons being lexicographic.



Also note the ordering of the results, which does appear to use numerical sorting (version "19.300.0.9" comes before "19.300.0.58" and "19.300.0.59").



Question: is it possible to force Artifactory to use numerical (SemVer) comparison in search criteria? If not, is there any other way I can exclude irrelevant versions from the result list?







artifactory artifactory-query-lang






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 25 at 13:59









KMZKMZ

3032 silver badges8 bronze badges




3032 silver badges8 bronze badges












  • .include("@rpm.metadata.version") .sort( "$asc": [ "name" ]) -- You have sorted the result in asc order with name field. Is this the earliest version greater than equal to19.300.0.58 ?

    – error404
    Mar 25 at 15:47











  • @error404: yes, I have sorted on the name field b/c sorting on properties (e.g. @rpm.metadata.version) is not supported. As a matter of fact, sort clause is irrelevant here: my main problem is that I have expected to get only two matches in the result (.58 and .59), but I am also getting a (much earlier) .9.

    – KMZ
    Mar 26 at 9:00











  • I feel the result is proper the version of the awesome_package-19.300.0.9-1.noarch.rpm would be higher than the previous one as this one ends with -1 instead of -0. If it would have been -0 then the result should not be part of the aql

    – error404
    Mar 26 at 9:54











  • @error404: -1 is in fact a property called @rpm.metadata.release, and is not related to @rpm.metadata.version property I use when searching. Artifactory correctly parses EVR (epoch/version/release) for deployed artifacts: if I search for artifacts using items.find( "$and" : [ "@rpm.metadata.name": "$eq": "awesome_package", "@rpm.metadata.version": "$eq": "19.300.0.9" ] ) I only get one result (as expected). It's just that $gte comparison treats version as a string, ignoring RPM spec that lays out (different) comparison semantics.

    – KMZ
    Mar 26 at 17:02







  • 1





    ok, I have not used the rpm so was not aware of the properties used. Can't you use created_by field to get the latest version ?

    – error404
    Mar 28 at 9:05

















  • .include("@rpm.metadata.version") .sort( "$asc": [ "name" ]) -- You have sorted the result in asc order with name field. Is this the earliest version greater than equal to19.300.0.58 ?

    – error404
    Mar 25 at 15:47











  • @error404: yes, I have sorted on the name field b/c sorting on properties (e.g. @rpm.metadata.version) is not supported. As a matter of fact, sort clause is irrelevant here: my main problem is that I have expected to get only two matches in the result (.58 and .59), but I am also getting a (much earlier) .9.

    – KMZ
    Mar 26 at 9:00











  • I feel the result is proper the version of the awesome_package-19.300.0.9-1.noarch.rpm would be higher than the previous one as this one ends with -1 instead of -0. If it would have been -0 then the result should not be part of the aql

    – error404
    Mar 26 at 9:54











  • @error404: -1 is in fact a property called @rpm.metadata.release, and is not related to @rpm.metadata.version property I use when searching. Artifactory correctly parses EVR (epoch/version/release) for deployed artifacts: if I search for artifacts using items.find( "$and" : [ "@rpm.metadata.name": "$eq": "awesome_package", "@rpm.metadata.version": "$eq": "19.300.0.9" ] ) I only get one result (as expected). It's just that $gte comparison treats version as a string, ignoring RPM spec that lays out (different) comparison semantics.

    – KMZ
    Mar 26 at 17:02







  • 1





    ok, I have not used the rpm so was not aware of the properties used. Can't you use created_by field to get the latest version ?

    – error404
    Mar 28 at 9:05
















.include("@rpm.metadata.version") .sort( "$asc": [ "name" ]) -- You have sorted the result in asc order with name field. Is this the earliest version greater than equal to19.300.0.58 ?

– error404
Mar 25 at 15:47





.include("@rpm.metadata.version") .sort( "$asc": [ "name" ]) -- You have sorted the result in asc order with name field. Is this the earliest version greater than equal to19.300.0.58 ?

– error404
Mar 25 at 15:47













@error404: yes, I have sorted on the name field b/c sorting on properties (e.g. @rpm.metadata.version) is not supported. As a matter of fact, sort clause is irrelevant here: my main problem is that I have expected to get only two matches in the result (.58 and .59), but I am also getting a (much earlier) .9.

– KMZ
Mar 26 at 9:00





@error404: yes, I have sorted on the name field b/c sorting on properties (e.g. @rpm.metadata.version) is not supported. As a matter of fact, sort clause is irrelevant here: my main problem is that I have expected to get only two matches in the result (.58 and .59), but I am also getting a (much earlier) .9.

– KMZ
Mar 26 at 9:00













I feel the result is proper the version of the awesome_package-19.300.0.9-1.noarch.rpm would be higher than the previous one as this one ends with -1 instead of -0. If it would have been -0 then the result should not be part of the aql

– error404
Mar 26 at 9:54





I feel the result is proper the version of the awesome_package-19.300.0.9-1.noarch.rpm would be higher than the previous one as this one ends with -1 instead of -0. If it would have been -0 then the result should not be part of the aql

– error404
Mar 26 at 9:54













@error404: -1 is in fact a property called @rpm.metadata.release, and is not related to @rpm.metadata.version property I use when searching. Artifactory correctly parses EVR (epoch/version/release) for deployed artifacts: if I search for artifacts using items.find( "$and" : [ "@rpm.metadata.name": "$eq": "awesome_package", "@rpm.metadata.version": "$eq": "19.300.0.9" ] ) I only get one result (as expected). It's just that $gte comparison treats version as a string, ignoring RPM spec that lays out (different) comparison semantics.

– KMZ
Mar 26 at 17:02






@error404: -1 is in fact a property called @rpm.metadata.release, and is not related to @rpm.metadata.version property I use when searching. Artifactory correctly parses EVR (epoch/version/release) for deployed artifacts: if I search for artifacts using items.find( "$and" : [ "@rpm.metadata.name": "$eq": "awesome_package", "@rpm.metadata.version": "$eq": "19.300.0.9" ] ) I only get one result (as expected). It's just that $gte comparison treats version as a string, ignoring RPM spec that lays out (different) comparison semantics.

– KMZ
Mar 26 at 17:02





1




1





ok, I have not used the rpm so was not aware of the properties used. Can't you use created_by field to get the latest version ?

– error404
Mar 28 at 9:05





ok, I have not used the rpm so was not aware of the properties used. Can't you use created_by field to get the latest version ?

– error404
Mar 28 at 9:05












1 Answer
1






active

oldest

votes


















1














Although not in lines with what is asked but instead of name sorting if done by the created field would also be helpful.



created:





share|improve this answer























  • thanks, upvoting your comment as an acceptable workaround.

    – KMZ
    Apr 1 at 11:50










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55339537%2fforce-artifactory-to-use-numerical-comparison-when-searching%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














Although not in lines with what is asked but instead of name sorting if done by the created field would also be helpful.



created:





share|improve this answer























  • thanks, upvoting your comment as an acceptable workaround.

    – KMZ
    Apr 1 at 11:50















1














Although not in lines with what is asked but instead of name sorting if done by the created field would also be helpful.



created:





share|improve this answer























  • thanks, upvoting your comment as an acceptable workaround.

    – KMZ
    Apr 1 at 11:50













1












1








1







Although not in lines with what is asked but instead of name sorting if done by the created field would also be helpful.



created:





share|improve this answer













Although not in lines with what is asked but instead of name sorting if done by the created field would also be helpful.



created:






share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 1 at 11:41









error404error404

1,1592 gold badges5 silver badges13 bronze badges




1,1592 gold badges5 silver badges13 bronze badges












  • thanks, upvoting your comment as an acceptable workaround.

    – KMZ
    Apr 1 at 11:50

















  • thanks, upvoting your comment as an acceptable workaround.

    – KMZ
    Apr 1 at 11:50
















thanks, upvoting your comment as an acceptable workaround.

– KMZ
Apr 1 at 11:50





thanks, upvoting your comment as an acceptable workaround.

– KMZ
Apr 1 at 11:50








Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.







Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.



















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55339537%2fforce-artifactory-to-use-numerical-comparison-when-searching%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현