OK, one last question for today before I start hacking at the text: You mention some methods here for multiple databases with a single entity:
http://groups.google.com/group/liftweb/msg/76c965c189a85103?pli=1 But looking in the code I can't find those methods. Are they essentially gone now? You also mentioned something better than sharding but I haven't seen anything on the list (maybe I missed it). Thanks, Derek On Thu, Dec 4, 2008 at 4:01 PM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote: > Cool. I guess I'm editing my chapter this afternoon now :) > > > On Thu, Dec 4, 2008 at 3:40 PM, David Pollak < > [EMAIL PROTECTED]> wrote: > >> >> >> On Thu, Dec 4, 2008 at 7:33 AM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote: >> >>> I'm mostly done with the rough draft of our Record/Mapper chapter and I >>> wanted to clarify a few points to make sure that my reading of the docs and >>> code is accurate: >>> >>> 1. ByRef appears to me to essentially be an old-style join (using the >>> where clause instead of join syntax). Is that accurate? Are there other >>> use >>> cases? >>> >>> >> This allows you to compare two columns in the same row. Because mapper >> does not allow for explicit joins or queries against more than one table at >> once (with the exception of the In construct), there's no "old style join" >> stuff. >> >> I've also changed the Join() QueryParam to PreCache... which is more >> descriptive of what it does. >> >> >>> >>> 1. >>> 2. It looks like the only way to get distinct results would be to use >>> the findAllByPreparedStatement or findAllByInsecureSql methods. Is there >>> some other way to do this that I'm missing? >>> >>> Or perhaps the Distrinct() QueryParam I just added. :-) >> >> >>> >>> 1. >>> 2. The toForm method in Mapper has an overload that takes a >>> redoSnippet. What is the use case for this? >>> >>> So you can keep the current state around over the course of multiple form >> submissions when the validation fails. >> >>> >>> 1. Will it be supported in Record or has that functionality been >>> folded into something else? >>> >>> I hope it will make it into Record/Field. >> >>> >>> 1. >>> 2. It appears that the functionality of the buildSet... methods in >>> MappedField has effectievly been replaced by the setFromAny in Field. Is >>> this the case, or will those buildSet functions show back up in some >>> subclass of field (it seems like there was a lot of overlap there) >>> >>> buildSet is JDBC specific and radically improves performance in >> converting a JDBC column to something that can be put into a field. >> >>> >>> 1. >>> 2. Am I reading correctly that Record no longer retains the orginal >>> value of a field when it's changed, but rather just flags the field as >>> dirty? (there are no is/was methods on Field) >>> >>> Probably... but there will be is/was on Field. It's a very helpful >> construct. >> >>> >>> 1. >>> >>> These last two make sense to me since it seems like duplicated effort for >>> #4 and not much of a use case on #5 that I can think of. Any info or >>> comments would be appreciated! >> >> >> Sure... wait a few minutes for my Distinct() checkin to make it to GitHub >> >> >>> >>> >>> Thanks, >>> >>> Derek >>> >>> >>> >> >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Collaborative Task Management http://much4.us >> Follow me: http://twitter.com/dpp >> Git some: http://github.com/dpp >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" 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/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
