This discussion is archived
1 2 Previous Next 25 Replies Latest reply: Oct 20, 2010 2:59 PM by 796367 Go to original post RSS
  • 15. Re: decide the really class instance used in runtime
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    pierrot_2 wrote:
    ...for example, most of my classes hold an<tt> int flags </tt>where I use a bitmask to extract the state of that object -- which would have made it nearly impossible for a code generator to predict how that information should be interpreted.
    I doubt that. However your statement doesn't make it clear what you are doing.

    I can only note that I have written many code generators. And manual customization at the class level is still possible with code generation. Just as it is possible at the SQL/proc level (where I often generate code as well.)
  • 16. Re: decide the really class instance used in runtime
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    pierrot_2 wrote:
    jverd wrote:
    18 tables and thousands of rows is minuscule.
    This because of the way I handle the data in the DB. First, I never delete rows, I recycle them. Each one of my classes has an<tt> int flags </tt> which I dedicate the first bit as a flag for delete. Instead of calling a DELETE, I update that bit to 1. This has saved my neck numerous times, because I have a good chance to recover it. An added benefit is that the numbers of rows never grows past a maximum capacity. For example, a TABLE named<tt> reminder </tt> contains data that does not need to persist past the expiration date. My<tt> static db_available() </tt> in that class scans the DB for expired or FLAGGED reminders and reuses that row.
    As phrased the last part of that doesn't make any sense. Anything even close to a RDMS is going to do something comparable to that description. Even MS Access. That is how page management works for deletes. Although MS Access doesn't do it as well as others.

    As for the first part there are at least two ways to maintain historical records. And per your description they would be more useful in more cases.
    $query = "SELECT customer_id WHERE customer_name LIKE 'A%'";
    Bad idea. You should use PreparedStatement.
    Not neccessary with my technique, because that query only returns a list of ID numbers, then I use a loop to create the desired object array with the already static SQL Query written into the class file.
    It isn't clear what your example is intended to demonstrate. However most people cannot use static SQL. They must populate it with data. And for those cases one must use a prepared statement for security reasons.
  • 17. Re: decide the really class instance used in runtime
    796440 Guru
    Currently Being Moderated
    pierrot_2 wrote:
    Not neccessary with my technique, because that query only returns a list of ID numbers, then I use a loop to create the desired object array with the already static SQL Query written into the class file.
    You should always use PreparedStatement. There's never a good reason to just use plain old Statement.

    PS saves you from having to quote and escape characters in strings (which is error-prone and can be a security risk) and from having to worry about formatting dates and times. It can also provide a performance benefit if you're repeating the same query lots of times with different parameters.
  • 18. Re: decide the really class instance used in runtime
    796367 Explorer
    Currently Being Moderated
    jschell wrote:
    As phrased the last part of that doesn't make any sense. Anything even close to a RDMS is going to do something comparable to that description. Even MS Access. That is how page management works for deletes. Although MS Access doesn't do it as well as others.
    Well this is where I didn't want my clients (customers) to actually DELETE anything from the DB. They have deleted things accidentally before, and because of the complexity of how the tables relate to each other, it is a real big mess when this happens. My plan is to use an<tt> int flags </tt>for each class or DB TABLE. That way, when my clients DELETE something, it is not really getting deleted in the database, what happens instead is that the first bit of the<tt> flags </tt>gets toggled to 1 and then UPDATED into the database. To the client, it looks like it has been deleted. I can use the<tt> msysql client tool </tt>to check for rows that have been flagged this way -- and if I need to recover the data, I just set that bit to 0... magic. So I don't even concern myself with how any database actually DELETES anything becuase I have absolutely no need for it -- no matter how good or bad the RDMS does it.
    As for the first part there are at least two ways to maintain historical records. And per your description they would be more useful in more cases.
    Another reason why I don't want my clients to actually perform DELETES.
    jschell wrote:
    pierrot_2 wrote:
    jverd wrote:
    pierrot_2 wrote:
    $query = "SELECT customer_id WHERE customer_name LIKE 'A%'";
    Bad idea. You should use PreparedStatement.
    Not neccessary with my technique, because that query only returns a list of ID numbers, then I use a loop to create the desired object array with the already static SQL Query written into the class file.
    It isn't clear what your example is intended to demonstrate. However most people cannot use static SQL. They must populate it with data. And for those cases one must use a prepared statement for security reasons.
    Don't look at this excerpt, it is severly truncated beyond recognition.
  • 19. Re: decide the really class instance used in runtime
    796367 Explorer
    Currently Being Moderated
    jverd wrote:
    pierrot_2 wrote:
    Not neccessary with my technique, because that query only returns a list of ID numbers, then I use a loop to create the desired object array with the already static SQL Query written into the class file.
    You should always use PreparedStatement. There's never a good reason to just use plain old Statement.
    I would have liked to, but unfortunately the system I'm running my app on is backed with a MySQL DB and PHP. I hear what you're saying.
    PS saves you from having to quote and escape characters in strings (which is error-prone and can be a security risk)
    Oh boy, ain't that the truth!
    ... and from having to worry about formatting dates and times. It can also provide a performance benefit if you're repeating the same query lots of times with different parameters.
    Haven't you read my book -- "Pierrots Big Adventure with UTC DateTime to PHP Date and Back" ? joke!
  • 20. Re: decide the really class instance used in runtime
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jverd wrote:
    pierrot_2 wrote:
    Not neccessary with my technique, because that query only returns a list of ID numbers, then I use a loop to create the desired object array with the already static SQL Query written into the class file.
    You should always use PreparedStatement. There's never a good reason to just use plain old Statement.
    It is possible that Statement might be slightly faster in very limited situations. That of course would be driven solely by profiling and a determination that alternative designs (which would be must faster) were not possible.
    PS saves you from having to quote and escape characters in strings (which is error-prone and can be a security risk) and from having to worry about formatting dates and times. It can also provide a performance benefit if you're repeating the same query lots of times with different parameters.
    The former is more likely the best reason than the latter. Specifically the latter is mentioned too much when someone does have a performance problem where it is unlikely that it will "fix" the problem.
  • 21. Re: decide the really class instance used in runtime
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    pierrot_2 wrote:
    jschell wrote:
    As phrased the last part of that doesn't make any sense. Anything even close to a RDMS is going to do something comparable to that description. Even MS Access. That is how page management works for deletes. Although MS Access doesn't do it as well as others.
    Well this is where I didn't want my clients (customers) to actually DELETE anything from the DB. They have deleted things accidentally before, and because of the complexity of how the tables relate to each other, it is a real big mess when this happens. My plan is to use an<tt> int flags </tt>for each class or DB TABLE. That way, when my clients DELETE something, it is not really getting deleted in the database, what happens instead is that the first bit of the<tt> flags </tt>gets toggled to 1 and then UPDATED into the database. To the client, it looks like it has been deleted. I can use the<tt> msysql client tool </tt>to check for rows that have been flagged this way -- and if I need to recover the data, I just set that bit to 0... magic. So I don't even concern myself with how any database actually DELETES anything becuase I have absolutely no need for it -- no matter how good or bad the RDMS does it.
    Which is just management of history. That requirement doesn't lead to anything to do with management of table size.
    As for the first part there are at least two ways to maintain historical records. And per your description they would be more useful in more cases.
    Another reason why I don't want my clients to actually perform DELETES.
    No idea what your comment means in the context of what you quoted.

    If it helps any I understand exactly how to implement history using one table with a delete marker. Again however that has nothing to do with table size.
    It isn't clear what your example is intended to demonstrate. However most people cannot use static SQL. They must populate it with data. And for those cases one must use a prepared statement for security reasons.
    Don't look at this excerpt, it is severly truncated beyond recognition.
    So you agree that one should use a prepared statement instead?
  • 22. Re: decide the really class instance used in runtime
    796440 Guru
    Currently Being Moderated
    jschell wrote:
    jverd wrote:
    pierrot_2 wrote:
    Not neccessary with my technique, because that query only returns a list of ID numbers, then I use a loop to create the desired object array with the already static SQL Query written into the class file.
    You should always use PreparedStatement. There's never a good reason to just use plain old Statement.
    It is possible that Statement might be slightly faster in very limited situations. That of course would be driven solely by profiling and a determination that alternative designs (which would be must faster) were not possible.
    Yup. But anybody who doesn't know that and realize that that is an exception to the "always" should just stick with "always". :-)

    >
    PS saves you from having to quote and escape characters in strings (which is error-prone and can be a security risk) and from having to worry about formatting dates and times. It can also provide a performance benefit if you're repeating the same query lots of times with different parameters.
    The former is more likely the best reason than the latter.
    That's the primary reason I use it. If I happen to get a performance benefit as well, that's a bonus, but I don't assume I will, and in most cases, I (and most people) probably don't.
    Specifically the latter is mentioned too much when someone does have a performance problem where it is unlikely that it will "fix" the problem.
    I haven't seen that personally, but I'm not at all surprised.
  • 23. Re: decide the really class instance used in runtime
    796367 Explorer
    Currently Being Moderated
    jschell wrote:
    So you agree that one should use a prepared statement instead?
    Oh yes definitely. And I also agreed with jverd when he mentioned it too.

    I guess my example led us off the beaten path because I was using a PHP scripting language instead of say, JSP -- where I definitely would have used a PreparedStatement. I also knew that when I posted my first example, that the concept I was trying to convey was not related to JAVA or any other platform or external service specifically... and that my ABSTRACT way of thinking may be a bit of a shock to anyone but myself.

    Even though I don't say it enough, I appreciate the level of knowledge and accuracy that you and the other members bring to these sometimes puzzling threads. I hope you don't freak out the next time I post something, because I have a lot of ideas that can be implemented by any language, platform, and or resource. In the meantime, I will try to keep my wording as close to context as possible.
  • 24. Re: decide the really class instance used in runtime
    796440 Guru
    Currently Being Moderated
    pierrot_2 wrote:
    jschell wrote:
    So you agree that one should use a prepared statement instead?
    I guess my example led us off the beaten path because I was using a PHP scripting language instead of say, JSP -- where I definitely would have used a PreparedStatement.
    No, you should not have any DB code in a JSP.
  • 25. Re: decide the really class instance used in runtime
    796367 Explorer
    Currently Being Moderated
    :) Look jverd, my first smiley and probably the last... ain't you a lucky ol' sod.
    jverd wrote:
    pierrot_2 wrote:
    jschell wrote:
    So you agree that one should use a prepared statement instead?
    I guess my example led us off the beaten path because I was using a PHP scripting language instead of say, JSP -- where I definitely would have used a PreparedStatement.
    No, you should not have any DB code in a JSP.
    I'll leave it as an exercise to the reader to figure out where they should be putting their DB code. I already have a good idea where to shove it.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points