bugPSPP - Bugs: bug #39252, Changing variable type in GUI...

 
 

bug #39252: Changing variable type in GUI clears data

Submitter:  Ben Pfaff <blp>
Submitted:  Fri 14 Jun 2013 06:51:29 AM UTC
   
 
Category:  Graphical User Interface Severity:  5 - Average
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  Before 0.8.0
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 19 Oct 2014 06:50:38 PM UTC, comment #13: 

Hi John,  I can confirm that when changing the variable type from string to any other choice it will wipe out the data in the column.  This is happening on both 32 bit and 64 bit windows versions (ver. PSPPIRE.exe 0.8.4-g607d3c )

Paul Roesler <proesler>
Sat 18 Oct 2014 06:09:07 AM UTC, comment #12: 

This item was closed over a year ago.  It should not happen with 0.8.4

I checked, and could not reproduce the problem with any recent version.

Are you seeing exactly the same symptoms as originally reported, or is it a different problem?


John Darrington <jmd>
Group administrator
Fri 17 Oct 2014 11:42:52 PM UTC, comment #11: 

Hi All,  I have just run into this problem and I am using PSPPIRE.exe 0.8.4-g607d3c on windows 7 64 bit.  Are there instructions on how to apply said patches?  I am not sure if there is a work around, perhaps assigning the variable type in the sps file?  Thanks in advance.

Paul Roesler <proesler>
Mon 24 Jun 2013 04:52:43 PM UTC, comment #10: 

I fixed this.

Thanks Ben for the review.

John Darrington <jmd>
Group administrator
Mon 24 Jun 2013 05:52:52 AM UTC, comment #9: 

The date patches look good to me too.  Thank you for finding and fixing these problems.

Ben Pfaff <blp>
Group administrator
Mon 24 Jun 2013 05:50:29 AM UTC, comment #8: 

I'm happy with the patches in mutate.tar.gz.  I didn't expect you to break the original patch into so many sub-patches, but it's nice.

I'll look at the date patches now.

Ben Pfaff <blp>
Group administrator
Sun 23 Jun 2013 10:24:54 AM UTC, comment #7: 

Here's another lot of patches to fix the problems associated with converting strings to dates (and perhaps other types too).

These patches need to be applied on top of the previous ones.


I think this just needs a final review and check-in.  Then this
item can be closed.

(file #28390)

John Darrington <jmd>
Group administrator
Sat 22 Jun 2013 10:51:11 AM UTC, comment #6: 

Round 2.

These patches are basically the same as before, but tidied up and incorporating Ben's comments.

If these are ok, I will push them. 

I still need to findout why dates encoded as strings cannot be changed to date variables.

(file #28387)

John Darrington <jmd>
Group administrator
Fri 21 Jun 2013 06:59:54 AM UTC, comment #5: 


> I see some memory leaks: some var_set_*() functions unconditionally clone the variable but only conditionally pass it to dict_var_changed().


I thought I had checked that.  I'll take another look.

> Each call to dict_var_changed() passes exactly one VAR_TRAIT_. If you don't expect that to change, then VAR_TRAIT_ does not need to be a bit-mask.


You are right.  I can foresee a time when the changes could be aggregated and one signal instead of several emitted.   ALTER TYPE might also benefit from being able to pass several TRAITS concurrently.

I'll rework this following your suggestions, and send it out for a second review.  I'll try to do them as separate changes to make the review easier.


John Darrington <jmd>
Group administrator
Fri 21 Jun 2013 04:46:27 AM UTC, comment #4: 

Thank you for working on this.  I think that this will work.

The more general var_changed() callback is nicer, I think.  Good idea.

This functionality is related to the ALTER TYPE command, which is unimplemented.  I don't know whether implementing ALTER TYPE would help.

I see some memory leaks: some var_set_*() functions unconditionally clone the variable but only conditionally pass it to dict_var_changed().

Each call to dict_var_changed() passes exactly one VAR_TRAIT_*.  If you don't expect that to change, then VAR_TRAIT_* does not need to be a bit-mask.

I think that the new version of var_clone() is a little harder to understand.  It would not need to change, if one added a helper function that called var_clone() if its argument variable's dictionary had a nonnull var_changed callback and simply returns NULL otherwise, and then each var_set_*() used that instead of calling var_clone() directly.

Ben Pfaff <blp>
Group administrator
Sun 16 Jun 2013 05:08:25 PM UTC, comment #3: 

This patch does much of the job.  But the changes have the potential to break other GUI functions, so it needs a good test and a review before checkin.

Tests are especially necessary for the gui functions which involve adding, deleting modifying variables using the gui.


It seems to work ok converting numeric to string, and when converting string to numeric for simple data types.  However,
it seems to have a problem when converting strings to  dates.  I don't know why.

(file #28328)

John Darrington <jmd>
Group administrator
Sun 16 Jun 2013 01:00:38 AM UTC, comment #2: 


>I can look at this one if you like.


Of course!  Please do.

Ben Pfaff <blp>
Group administrator
Sat 15 Jun 2013 08:08:06 AM UTC, comment #1: 

I can look at this one if you like.

John Darrington <jmd>
Group administrator
Fri 14 Jun 2013 06:51:29 AM UTC, original submission:  

dr soumalya ray <drsoumalya-ray@yahoo.co.in> reported on pspp-users:

> in PSPP changing the variable type from, say numeric to string or vice-versa, will delete the whole variable.
>
>
> steps:
> 1. launch psppire
> 2. create 2 variables- var1 and var2
> 3. change variable type of var2 to "string"
> 4. enter some data under var1 and var2 (say, 1,2,3,4,5 etc)
> 5. now, again go to the variable view
> 6. change the variable type from "numeric" to "string" for var1
> 7. go to the data view
> 8. all entry under var1 is deleted
> 9. for var2, variable type could be changed from "string" to "numeric" and it will result in the same thing- loss of all data under var2.
> 10. the output in the terminal - "(psppire:28002): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent."


Ben Pfaff <blp>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #28390:  date-conversion.tar.gz added by jmd (3KiB - application/x-gzip)
file #28387:  mutate.tar.gz added by jmd (11KiB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by proesler (Posted a comment)
  • -email is unavailable- added by jmd (Posted a comment)
  • -email is unavailable- added by blp (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-06-24 jmd StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2013-06-23 jmd Attached File- Added date-conversion.tar.gz, #28390
    2013-06-22 jmd Attached File- Added mutate.tar.gz, #28387
    2013-06-16 jmd Attached File- Added 0001-Convert-data-to-and-from-string-values-when-the-gui-.patch, #28328
        StatusConfirmed In Progress
    2013-06-14 blp ReleaseNone Before 0.8.0

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code