Loading ...
Sorry, an error occurred while loading the content.

2.5 Update

Expand Messages
  • taffydb-owner@yahoogroups.com
    Just pushed out a 2.5 update with a possible breaking change. Updates: A. Filters {key:value} and {key:{is:value}} now do type coercion. So if you re column
    Message 1 of 8 , Jun 15, 2012
    • 0 Attachment
      Just pushed out a 2.5 update with a possible breaking change.

      Updates:

      A. Filters {key:value} and {key:{is:value}} now do type coercion. So if you're column contains 1 and your search value is "1" they will still match. This is consistent with the Taffy 1.X branch but is new to 2.X
      B. Introduction of filter {key:{exact:value}} to compare on types and values at the same type.
      C. Fixed bug with update where type coercion was in use to try and detect changes. In same cases it prevent updates.
      D. Introduced db.merge() function that will take an array of records (perhaps from the server), and merge then on a key (such as ID) into an existing DB.

      Let me know if you have any questions or run into any issues.
    • Michael Mikowski
      I understand the demand for such a change, but type coercion seems like a step backwards. If I rely on type coercion, I will get get into trouble, if not in
      Message 2 of 8 , Jun 16, 2012
      • 0 Attachment
        I understand the demand for such a change, but type coercion seems like a step backwards. If I rely on type coercion, I will get get into trouble, if not in taffyDB, then elsewhere.

        Sent from my ASUS Transformer Prime
      • taffydb-owner@yahoogroups.com
        Thanks for your comment and feedback. I m not super happy with it either so I m very open to better ideas. What I want (and maybe I m wrong here) is for the
        Message 3 of 8 , Jun 18, 2012
        • 0 Attachment
          Thanks for your comment and feedback. I'm not super happy with it either so I'm very open to better ideas. What I want (and maybe I'm wrong here) is for the default search {key:value} and {key:{is:value}} to do the most useful thing possible. This keeps with the theme of having TaffyDB "do the right thing".

          Here is a good article on the topic:

          http://webreflection.blogspot.com/2010/10/javascript-coercion-demystified.html

          A common error that comes my way comes from the interaction of browsers with JavaScript. So from a URL or a Form you may end up with a number that is cast as type string that is being compared to a number inside a TaffyDB. I'd like "is" matching to more or less only compare about values, not types. So if the value of a record is a string and you try and compare it to a number of the same value the match is true. Unless you use {key:{exact:value}}.

          I'll really open to thoughts on if this is a good idea and how to better do it. In the next build or two I'd like to look at support for the "is" filter doing the following:

          comparing an object to a json string
          comparing a string to a number
          comparing a date to a string (that converts to a date)
          comparing a boolean to a number (0 or 1) or a string ("0" or "1" or "true" or "false")

          This could open up a new class of error, however my experience is that the opposite error is far more common where you take a number from a drop down to run a search on and nothing is returned so you think TaffyDB is broken.

          Thoughts?

          Ian


          --- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
          >
          > I understand the demand for such a change, but type coercion seems like a step backwards. If I rely on type coercion, I will get get into trouble, if not in taffyDB, then elsewhere.
          >
          > Sent from my ASUS Transformer Prime
          >
        • Michael Mikowski
          Maybe this is crazy or too big a jump, but how about this: { key : { === : value } In other words, use the exact js comparison syntax for the match. And if
          Message 4 of 8 , Jun 18, 2012
          • 0 Attachment
            Maybe this is crazy or too big a jump, but how about this:

            { key : { '===' : value }

            In other words, use the exact js comparison syntax for the match. And if we want type coercion we might do this:

            { key : { '==' : value }

            Or { key : { '!=' : value } vs { key : { '!==' : value }

            ... ?




            Sent from my ASUS Eee Pad

            taffydb-owner@yahoogroups.com wrote:

             

            Thanks for your comment and feedback. I'm not super happy with it either so I'm very open to better ideas. What I want (and maybe I'm wrong here) is for the default search {key:value} and {key:{is:value}} to do the most useful thing possible. This keeps with the theme of having TaffyDB "do the right thing".

            Here is a good article on the topic:

            http://webreflection.blogspot.com/2010/10/javascript-coercion-demystified.html

            A common error that comes my way comes from the interaction of browsers with JavaScript. So from a URL or a Form you may end up with a number that is cast as type string that is being compared to a number inside a TaffyDB. I'd like "is" matching to more or less only compare about values, not types. So if the value of a record is a string and you try and compare it to a number of the same value the match is true. Unless you use {key:{exact:value}}.

            I'll really open to thoughts on if this is a good idea and how to better do it. In the next build or two I'd like to look at support for the "is" filter doing the following:

            comparing an object to a json string
            comparing a string to a number
            comparing a date to a string (that converts to a date)
            comparing a boolean to a number (0 or 1) or a string ("0" or "1" or "true" or "false")

            This could open up a new class of error, however my experience is that the opposite error is far more common where you take a number from a drop down to run a search on and nothing is returned so you think TaffyDB is broken.

            Thoughts?

            Ian

            --- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
            >
            > I understand the demand for such a change, but type coercion seems like a step backwards. If I rely on type coercion, I will get get into trouble, if not in taffyDB, then elsewhere.
            >
            > Sent from my ASUS Transformer Prime
            >

          • taffydb-owner@yahoogroups.com
            It is a really clever idea that is for sure. I like it assuming that === and != are valid keys on an object. I ll look into it. It still leads to a
            Message 5 of 8 , Jun 18, 2012
            • 0 Attachment
              It is a really clever idea that is for sure. I like it assuming that '===' and '!=' are valid keys on an object. I'll look into it.

              It still leads to a question though, what should the default {column:value} search do? I'm inclined to make it greedy, especially if we are giving you better ways to be more particular about how you match.

              --- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
              >
              > Maybe this is crazy or too big a jump, but how about this:
              >
              > { key : { '===' : value }
              >
              > In other words, use the exact js comparison syntax for the match. And if we want type coercion we might do this:
              >
              > { key : { '==' : value }
              >
              > Or { key : { '!=' : value } vs { key : { '!==' : value }
              >
              > ... ?
              >
              >
            • David Kantowitz
              Any string is a valid key for an object. Keys that aren t identifiers can t be accessed using the dot operator, but still work fine with brackets. ex. var a =
              Message 6 of 8 , Jun 18, 2012
              • 0 Attachment
                Any string is a valid key for an object.  Keys that aren't identifiers can't be accessed using the dot operator, but still work fine with brackets. 

                ex.

                var a = {'===':10};
                a.===  // syntax error
                a['==='] // ok


                On Mon, Jun 18, 2012 at 9:34 PM, <taffydb-owner@yahoogroups.com> wrote:
                 

                It is a really clever idea that is for sure. I like it assuming that '===' and '!=' are valid keys on an object. I'll look into it.

                It still leads to a question though, what should the default {column:value} search do? I'm inclined to make it greedy, especially if we are giving you better ways to be more particular about how you match.

                --- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
                >
                > Maybe this is crazy or too big a jump, but how about this:
                >
                > { key : { '===' : value }
                >
                > In other words, use the exact js comparison syntax for the match. And if we want type coercion we might do this:
                >
                > { key : { '==' : value }
                >
                > Or { key : { '!=' : value } vs { key : { '!==' : value }
                >
                > ... ?
                >
                >


              • Michael Mikowski
                I am happy you like the suggestion :-) I would again suggest using exact match as default behavior (I know, surprise!) 2 reasons: 1. type coercion is a big
                Message 7 of 8 , Jun 19, 2012
                • 0 Attachment
                  I am happy you like the suggestion :-)

                  I would again suggest using exact match as default behavior (I know, surprise!) 2 reasons:

                  1. type coercion is a big source of subtle javascript errors. Making the default behavior best practice seems like the right thing to do.

                  2. And my hunch is exact match may be significantly faster over large data sets (although I have not tested, yet).

                  Let me know if you would like some help ... I could do a mockup tomorrow.

                  Cheers, Mike

                  Sent from my ASUS Eee Pad

                  taffydb-owner@yahoogroups.com wrote:

                   

                  It is a really clever idea that is for sure. I like it assuming that '===' and '!=' are valid keys on an object. I'll look into it.

                  It still leads to a question though, what should the default {column:value} search do? I'm inclined to make it greedy, especially if we are giving you better ways to be more particular about how you match.

                  --- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
                  >
                  > Maybe this is crazy or too big a jump, but how about this:
                  >
                  > { key : { '===' : value }
                  >
                  > In other words, use the exact js comparison syntax for the match. And if we want type coercion we might do this:
                  >
                  > { key : { '==' : value }
                  >
                  > Or { key : { '!=' : value } vs { key : { '!==' : value }
                  >
                  > ... ?
                  >
                  >

                • taffydb-owner@yahoogroups.com
                  My understanding is that == is actually faster than === over large data sets although I haven t verified. I like the suggests and will implement them for now.
                  Message 8 of 8 , Jun 19, 2012
                  • 0 Attachment
                    My understanding is that == is actually faster than === over large data sets although I haven't verified.

                    I like the suggests and will implement them for now. I still think the default {column:value} is something that can and perhaps should be a little smarter than exact match. But we'll cross that bridge when we get to it.

                    --- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
                    >
                    > I am happy you like the suggestion :-)
                    >
                    > I would again suggest using exact match as default behavior (I know, surprise!) 2 reasons:
                    >
                    > 1. type coercion is a big source of subtle javascript errors. Making the default behavior best practice seems like the right thing to do.
                    >
                    > 2. And my hunch is exact match may be significantly faster over large data sets (although I have not tested, yet).
                    >
                    > Let me know if you would like some help ... I could do a mockup tomorrow.
                    >
                    > Cheers, Mike
                    >
                    > Sent from my ASUS Eee Pad
                    >
                    > taffydb-owner@yahoogroups.com wrote:
                    >
                    > >It is a really clever idea that is for sure. I like it assuming that '===' and '!=' are valid keys on an object. I'll look into it.
                    > >
                    > >It still leads to a question though, what should the default {column:value} search do? I'm inclined to make it greedy, especially if we are giving you better ways to be more particular about how you match.
                    > >
                    > >--- In taffydb@yahoogroups.com, Michael Mikowski <z_mikowski@> wrote:
                    > >>
                    > >> Maybe this is crazy or too big a jump, but how about this:
                    > >>
                    > >> { key : { '===' : value }
                    > >>
                    > >> In other words, use the exact js comparison syntax for the match. And if we want type coercion we might do this:
                    > >>
                    > >> { key : { '==' : value }
                    > >>
                    > >> Or { key : { '!=' : value } vs { key : { '!==' : value }
                    > >>
                    > >> ... ?
                    > >>
                    > >>
                    > >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.