nikhilgupta10
commented
7 years ago nikhilgupta10 imported these comments from Sourceforge: The user dchassin does not exist anymore. Therefore assigning this to afisher1. "jcfuller": * owner changed from mhauer to jhammerstrom
- priority changed from blocker to major
- status changed from new to assigned
- type changed from enhancement to validation
I believe these are all taken care of. Please review and determine whether these improvements have been merged into trunk / v3.0.
,
"dchassin":- Description has changed:
Diff:
--- old
+++ new
@@ -1,14 +1,11 @@
There are a few things that would make working within the mysql module a little easier and more in line with what recorders/players currently are capable of:
-/u2022 Right now a recorder object creates a table in the schema with columns for auto increment ID, simulation timestamp, and recorded property. I think we need another column in this table that records the name of the .glm.
+1) Right now a recorder object creates a table in the schema with columns for auto increment ID, simulation timestamp, and recorded property. I think we need another column in this table that records the name of the .glm.
+2) There is a /u201cmode/u201d property (w or w+ rewrites the data into the table each simulation, and a or a+ is supposed to append new records to the table). It appears that the append function is not working as expected, and I think we need that.
-/u2022 There is a /u201cmode/u201d property (w or w+ rewrites the data into the table each simulation, and a or a+ is supposed to append new records to the table). It appears that the append function is not working as expected, and I think we need that.
+3) The recorder object won/u2019t let us record real and imaginary parts of properties separately via .real and .imag. It also won/u2019t let us record more than one property in a table (i.e. property /u201cInsolation, VA_Out/u201d). The collector object handles these things as expected, creating a column in the table for each property and handling .real and .imag.
+4) The mysql module was written so that it would be very easy to convert tape objects to mysql objects, but it looks like we can/u2019t use both modules in one .glm now. This is only a problem for us if we want to read any players from files (i.e. voltage players) instead of putting them into MySQL. Seems like it would be nice to be able to choose whether an object in your file uses mysql or tape.
-/u2022 The recorder object won/u2019t let us record real and imaginary parts of properties separately via .real and .imag. It also won/u2019t let us record more than one property in a table (i.e. property /u201cInsolation, VA_Out/u201d). The collector object handles these things as expected, creating a column in the table for each property and handling .real and .imag.
-
-
-/u2022 The mysql module was written so that it would be very easy to convert tape objects to mysql objects, but it looks like we can/u2019t use both modules in one .glm now. This is only a problem for us if we want to read any players from files (i.e. voltage players) instead of putting them into MySQL. Seems like it would be nice to be able to choose whether an object in your file uses mysql or tape.
-
- Resolution: --> none
- Component: Tape --> none
-
Type: validation --> defect ,
"dchassin":Review findings after inspection of MySQL module code in trunk (r4762).
1) A field for the .glm file does not appear to be implemented. This may not be a good solution to the problem of identify which data in a table comes from which run. The .glm file name is nominally 1024 characters and is something that should be indexed to a session table so that all the data from a particular run can be identified clearly.
2) The MO_DROPTABLES option appears to be coded correctly. We will need a test for this thought and there is none.
3) There is no code in sync to handle complex numbers, so this doesn't appear to be implemented.
4) The solution to this problem is to disambiguate the \object
One note: renaming autotest to autotest-disabled is not the correct way to disable autotesting of a module. The correct way is to create a file called autotest.no in the module folder. Trunk will be modified soon to ensure that this is done correctly.,
"dchassin":- status: assigned --> accepted
- assigned_to: Janelle Hammerstrom --> David P. Chassin
- Component: none --> mysql
- Version: 3.0 --> trunk
-
Type: defect --> enhancement ,
"dchassin":- Milestone: Unscheduled --> Version 4.0 RC1 ,
There are a few things that would make working within the mysql module a little easier and more in line with what recorders/players currently are capable of:
1) Right now a recorder object creates a table in the schema with columns for auto increment ID, simulation timestamp, and recorded property. I think we need another column in this table that records the name of the .glm.
2) There is a /u201cmode/u201d property (w or w+ rewrites the data into the table each simulation, and a or a+ is supposed to append new records to the table). It appears that the append function is not working as expected, and I think we need that.
3) The recorder object won/u2019t let us record real and imaginary parts of properties separately via .real and .imag. It also won/u2019t let us record more than one property in a table (i.e. property /u201cInsolation, VA_Out/u201d). The collector object handles these things as expected, creating a column in the table for each property and handling .real and .imag.
4) The mysql module was written so that it would be very easy to convert tape objects to mysql objects, but it looks like we can/u2019t use both modules in one .glm now. This is only a problem for us if we want to read any players from files (i.e. voltage players) instead of putting them into MySQL. Seems like it would be nice to be able to choose whether an object in your file uses mysql or tape.
,