Actually, now that you mention it, we currently generate the tombstones in the client and send them over like normal inserts. We could add a "generate_tombstones" flag to the scanner and generate the tombstones in the RangeServer. That would avoid requiring a two operation transaction for handling range deletes.
- Doug On Thu, Aug 9, 2012 at 5:21 PM, Sanjit Jhala <[email protected]> wrote: > I was under the impression that adding SELECT functionality to DELETEs > involves more than just parser changes, ie something like the MergeScanner > logic to figure out which cells you need to insert delete records for. > > -Sanjit > > On Thu, Aug 9, 2012 at 4:48 PM, Doug Judd <[email protected]> wrote: > >> Hi Sanjit, >> >> Comments inline ... >> >> On Thu, Aug 9, 2012 at 4:05 PM, Sanjit Jhala <[email protected]> wrote: >> >>> Hi Doug, >>> >>> I am not too crazy about removing the DELETE command. In my mind, HQL >>> syntax needs to be heavily biased towards existing SQL users as opposed to >>> being the cleanest syntax for Hypertable power users (if you're a power >>> user, you really shouldn't be using HQL for anything other than sanity >>> checks and administrative tasks anyway :) ). Correct me if I'm wrong, but I >>> think one of the main goals of HQL is to be similar to SQL. I would lean >>> towards leaving the existing DELETE in place for now and overhauling it >>> sometime in the future. >>> >> >> Ok, you're the third person to respond with this feedback. We'll leave >> the DELETE command in and plan to overhaul it later. >> >> >>> I think it does make sense to augment the INSERT command. It sounds like >>> your changes won't break the existing insert syntax, but add the ability >>> insert delete records. This makes complete sense to and the curious user >>> and look through the documentation to figure out that deletes are actually >>> inserts. (On a side note, is there a clean way to add functionality to the >>> new insert to delete the last 'n' versions (without knowing the timestamps) >>> ?) >>> >> >> Ok, sounds good. We currently don't have a way to delete the last 'n' >> versions. I don't recall anyone asking for it, but might not be too >> difficult to implement if we commandeer the unused value to hold a count. >> >> >>> I'm also not sure if making the DELETE command support all the >>> predicates that SELECT does is worth the effort at this point. SELECT is >>> quite involved as it is, and I'm not sure its worth jumping through to all >>> the hoops required to implement that. >>> >> >> Well, if we're overhauling the parser anyway, it wouldn't be too >> difficult to re-use the same sub-parser for the SELECT predicate as well >> as the DELETE predicate. It seems like having one consistent syntax for >> specifying cells of interest would be good. >> >> Thanks for your feedback! >> >> - Doug >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Hypertable Development" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/hypertable-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Hypertable Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/hypertable-dev?hl=en. > -- Doug Judd CEO, Hypertable Inc. -- You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en.
