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

Where does TaffyDB hold the data?

Expand Messages
  • frank_berger_software@ymail.com
    Hello Ian, I am still quite new to JavaScript (only 4 months in JS, after 20 yrs in pure o-o systems) and I have played with TaffyDB for about a day. It would
    Message 1 of 5 , Dec 2, 2009
    • 0 Attachment
      Hello Ian,

      I am still quite new to JavaScript (only 4 months in JS, after >20 yrs in pure o-o systems) and I have played with TaffyDB for about a day. It would fit perfectly into my projects but I have a few subjects that I would like to have resolved.

      1) I have a very bad feeling, simply because I don't see the data in the debugger.

      I used your (unfortunately only one) example "friends" and things work but when I look into Firebug I can't see any holder of the data. It's as though TaffyDB has "swallowed" all into some invisbile somewhere.

      That deeply irritates me!

      Also, what I find most disturbing is that there seems to be neither some direct access to some data holder, nor any "getById" (which was critizised already here on the forum). I would expect performance problems when having to access complex data via a "get()" each time that I need to access the data. I my view, every data object MUST have a unique ID, whether in a physical table, or in memory.

      Additionally, I will have to add complex objects ("real" objects versus JS Arrays) based on JOOSE to the data holder inside Taffy. And I am most afraid of that if I can't even see where the data goes not to mention can control where it is stored. I hate black boxes!

      Reading your quite cryptic code does (for my taste) not help me much either, because I am not an JS expert and because I have always had problems with this C-style cryptic form of writing code. I am not a systems programmer and won't become one.

      Beyond these "little" problems I think that you have done a very good job - provided Taffy does what is claimed and that is what I would like to find out.

      Two thoughts for extending Taffy:

      1) My app is based on Ext and I am planning to develop a generic "interface" between Taffy and Ext grids and forms or rather between some controller classes (in good o-o MVS style) that manage the Ext grids in order to simplify the communication between these components.

      If you are interested, I would contribute this to your Taffy project. I could imagine that there is quite some interest in the very large Ext community of around 90.000 users on their forum.

      2) I think it would be a great idea to create a bridge to SQL in general and to MySQL in particular. That could be an add-on that you should license against some fee as nobody can expect such a thing for free.

      I would very much like to have such a bridge around spring next year, because by then I hope to bring out my second release based on a web server and that should ideally correspond with the Taffy filtering engine in the browser. I am quite sure that this is feasible also,because in our o-o server software we are using some essentially similar SQL condition objects (Dictionarys) like you are in Taffy. That just has to be made compatible.

      If you are essentially interested, I would like to discuss this with you via email or PN.

      As for today, I am hoping for some answer to the "where is my data" question, which currently hinders me form using Taffy.

      Best regards
      Frank
    • tacoman_cool
      Hi Frank, 1. The data is held via a closure as an internal variable. This has advantages and disadvantages, but the primary advantage is that the data is
      Message 2 of 5 , Dec 2, 2009
      • 0 Attachment
        Hi Frank,

        1. The data is held via a closure as an internal variable. This has advantages and disadvantages, but the primary advantage is that the data is protected and not directly accessible. You can of course .get() all the data at anytime, but you can't update or modify the data directly without using one of the provide methods.

        2. In practice you have both a viable "getByID" option as well as direct access. Since the data inside of TaffyDB is really just an array you can access it by index number.

        So if you had a collection you could "find" the index for a set of items like this:

        mystuff.find({something:1}) // returns an array of indexes where something = 1, [0,1,2,3,4] for example

        You can exact records by index:

        var records = mystuff.get(1);

        By array of index:

        var records = mystuff.get([0,1,2,3,4]);

        Or by a filter (to skip the find step):

        var records = mystuff.get({something:1});

        Likewise the real magic of TaffyDB happens when you start using forEach.

        mystuff.forEach(function (r,i) {
        // r = the object for this record
        // i = the index of this record (0 for example)

        },[0,1,2,3,4]);

        You can replace the array of indexes with a single index or a filter just like get(). In practice I often use the indexes as ids when working with the data. Just be aware that the index of the records is not static and could change if you delete records or use the orderBy method.

        3. As for using a debugger, I defiantly agree with you that having access would make it a lot simpler. It could be that I could create a debugger version of Taffy to give you easier access. What debugging tools are you using?

        3. My background is more functional than oo so that explains some of the approach I took to coding it out. The other reasons were speed and file size as I've gone through a number of times and greatly minimized the amount of code to make sure TaffyDB isn't a burden to bring into your app.

        4. You hit the nail on the head. TaffyDB is really a utility library that would work well as the backbone for all sorts of apps, but I personally don't want to see it try and compete with the ajax libraries out there. Bridge code to bring it nicely into Jquery, Ext, YUI, etc would be huge and I'd be very interested in what you put together.

        5. As for a SQL bridge, I've had some ideas in that area although there are problems as well. I'll shoot you an email offline and we can discuss.

        Ian

        --- In taffydb@yahoogroups.com, "frank_berger_software@..." <frank_berger_software@...> wrote:
        >
        > Hello Ian,
        >
        > I am still quite new to JavaScript (only 4 months in JS, after >20 yrs in pure o-o systems) and I have played with TaffyDB for about a day. It would fit perfectly into my projects but I have a few subjects that I would like to have resolved.
        >
        > 1) I have a very bad feeling, simply because I don't see the data in the debugger.
        >
        > I used your (unfortunately only one) example "friends" and things work but when I look into Firebug I can't see any holder of the data. It's as though TaffyDB has "swallowed" all into some invisbile somewhere.
        >
        > That deeply irritates me!
        >
        > Also, what I find most disturbing is that there seems to be neither some direct access to some data holder, nor any "getById" (which was critizised already here on the forum). I would expect performance problems when having to access complex data via a "get()" each time that I need to access the data. I my view, every data object MUST have a unique ID, whether in a physical table, or in memory.
        >
        > Additionally, I will have to add complex objects ("real" objects versus JS Arrays) based on JOOSE to the data holder inside Taffy. And I am most afraid of that if I can't even see where the data goes not to mention can control where it is stored. I hate black boxes!
        >
        > Reading your quite cryptic code does (for my taste) not help me much either, because I am not an JS expert and because I have always had problems with this C-style cryptic form of writing code. I am not a systems programmer and won't become one.
        >
        > Beyond these "little" problems I think that you have done a very good job - provided Taffy does what is claimed and that is what I would like to find out.
        >
        > Two thoughts for extending Taffy:
        >
        > 1) My app is based on Ext and I am planning to develop a generic "interface" between Taffy and Ext grids and forms or rather between some controller classes (in good o-o MVS style) that manage the Ext grids in order to simplify the communication between these components.
        >
        > If you are interested, I would contribute this to your Taffy project. I could imagine that there is quite some interest in the very large Ext community of around 90.000 users on their forum.
        >
        > 2) I think it would be a great idea to create a bridge to SQL in general and to MySQL in particular. That could be an add-on that you should license against some fee as nobody can expect such a thing for free.
        >
        > I would very much like to have such a bridge around spring next year, because by then I hope to bring out my second release based on a web server and that should ideally correspond with the Taffy filtering engine in the browser. I am quite sure that this is feasible also,because in our o-o server software we are using some essentially similar SQL condition objects (Dictionarys) like you are in Taffy. That just has to be made compatible.
        >
        > If you are essentially interested, I would like to discuss this with you via email or PN.
        >
        > As for today, I am hoping for some answer to the "where is my data" question, which currently hinders me form using Taffy.
        >
        > Best regards
        > Frank
        >
      • frank_berger_software@ymail.com
        Hello Ian, First of all, thank you very much for your *extremely quick* and *extremely detailed* response! I appreciate that very much ! My compliments. ...
        Message 3 of 5 , Dec 2, 2009
        • 0 Attachment
          Hello Ian,

          First of all, thank you very much for your *extremely quick* and *extremely detailed* response! I appreciate that very much ! My compliments.

          A few comments below into your answers:


          > 1. The data is held via a closure as an internal variable. This has advantages and disadvantages, but the primary advantage is that the data is protected and not directly accessible.

          Ok, that's some internal JS "magic" that I had not yet come about with my little JS experience (and I don't want to become a JS expert anyway).

          >
          > 2. In practice you have both a viable "getByID" option as well as direct access. Since the data inside of TaffyDB is really just an array you can access it by index number.

          In the meantime I made some more tests and found positive results on this.

          > 3. ...What debugging tools are you using?
          Firebug (which for me is rather "Flinbug", stone-age compared to my o-o environments). I am not aware of anything "less bad", i.e. comparably better.

          > 3. My background is more functional than oo so that explains some of the approach I took to coding it out.
          That's ok and certainly much better for performance. O-o means lot's of overhead.

          > 4. I'd be very interested in what you put together.
          I will keep you posted regarding my work to integrate it with Ext grids and forms.

          > 5. As for a SQL bridge, I've had some ideas in that area although there are problems as well. I'll shoot you an email offline and we can discuss.
          Fine, I would also prefer to discuss this directly via email. Please contact me on frank.berger.software at the domain web.de.

          I will also let you know more details via email on my products and projects.

          Your response made me decide to give Taffy a try for my project.

          Regards
          Frank
        • tacoman_cool
          Frank, Excellent, glad you are going to give it a go. Let us know what feedback you have. Briefly I wanted to attempt to explain closure as well as it is a
          Message 4 of 5 , Dec 2, 2009
          • 0 Attachment
            Frank,

            Excellent, glad you are going to give it a go. Let us know what feedback you have.

            Briefly I wanted to attempt to explain closure as well as it is a very cool natural part of JavaScript. Many have failed to explain it before so forgive me if I follow in their footsteps :-)

            A "closure" happens when you have a function inside of another function. It effectively create a private variable space and provide the ability to have privileged methods and other oo concepts not otherwise doable in JavaScript.

            Here is an example:

            var person = function () {
            var stepsTaken = 0;
            return {
            takeStep:function () {
            stepsTaken++;
            }
            }
            }

            ian = person();

            ian.takeStep();

            Because we define the takeStep function inside of the person function it gets a closure that lets it access the private stepsTaken variable. It then can modify it but there is no other way to get access to that variable unless you add another method:

            var person = function () {
            var stepsTaken = 0;
            return {
            takeStep:function () {
            stepsTaken++;
            },
            howManySteps:function () {
            return stepsTaken;
            }
            }
            }

            You could then call ian.howManySteps() to see how many you'd take so far. Both functions have access to the same variables so there is only one stepsTaken variable per person you've created.

            Hopefully that makes sense :-)

            Ian

            --- In taffydb@yahoogroups.com, "frank_berger_software@..." <frank_berger_software@...> wrote:
            >
            >
            >
            >
            > Hello Ian,
            >
            > First of all, thank you very much for your *extremely quick* and *extremely detailed* response! I appreciate that very much ! My compliments.
            >
            > A few comments below into your answers:
            >
            >
            > > 1. The data is held via a closure as an internal variable. This has advantages and disadvantages, but the primary advantage is that the data is protected and not directly accessible.
            >
            > Ok, that's some internal JS "magic" that I had not yet come about with my little JS experience (and I don't want to become a JS expert anyway).
            >
            > >
            > > 2. In practice you have both a viable "getByID" option as well as direct access. Since the data inside of TaffyDB is really just an array you can access it by index number.
            >
            > In the meantime I made some more tests and found positive results on this.
            >
            > > 3. ...What debugging tools are you using?
            > Firebug (which for me is rather "Flinbug", stone-age compared to my o-o environments). I am not aware of anything "less bad", i.e. comparably better.
            >
            > > 3. My background is more functional than oo so that explains some of the approach I took to coding it out.
            > That's ok and certainly much better for performance. O-o means lot's of overhead.
            >
            > > 4. I'd be very interested in what you put together.
            > I will keep you posted regarding my work to integrate it with Ext grids and forms.
            >
            > > 5. As for a SQL bridge, I've had some ideas in that area although there are problems as well. I'll shoot you an email offline and we can discuss.
            > Fine, I would also prefer to discuss this directly via email. Please contact me on frank.berger.software at the domain web.de.
            >
            > I will also let you know more details via email on my products and projects.
            >
            > Your response made me decide to give Taffy a try for my project.
            >
            > Regards
            > Frank
            >
          • frank_berger_software@ymail.com
            Thanks a lot. I looked it up. I wasn t aware of such system stuff - and I keep a safe distance from such issues. I am in applications and C-like hacking is not
            Message 5 of 5 , Dec 2, 2009
            • 0 Attachment
              Thanks a lot. I looked it up. I wasn't aware of such system stuff - and I keep a safe distance from such issues. I am in applications and C-like hacking is not my turf.

              Regards
              Frank
            Your message has been successfully submitted and would be delivered to recipients shortly.