Releases: cgspeck/brewtarget
Releases · cgspeck/brewtarget
2.3.1.r1501: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1500: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1499: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1498: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1497: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1496: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1495: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1494: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1493: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.
2.3.1.r1492: Closes issue #475 and #476 (#477)
Importing an XML that we exported threw errors. Imagine my embarrassment. One significant issue was when dealing with attributes that we store in memory as an enumerated type, but translate to a string when writing it to XML (or the database). Like hop.use and hop.useString. TableSchema::propertyToXml() searched only by the name of the property name (useString in this example) and not the key in the Map. This is fixed. Another issue was some misspellings in the schema files that prevented the import to find the right type. These have been fixed, and should have no impact on anybody. I also rearranged the interactions a little. Popping a QMessage box for every mashstep that we couldn't figure out was annoying. Now it warns on the console. The final fix was that I realized the default_database.sqlite had a bad schema for brewnotes and did not have the notes column defined. I am fairly certain this shouldn't have hurt anybody, as there was no code written to actually drop the column.