On Feb 15, 10:00 pm, BigBaaadBob <[email protected]> wrote: > Yes, that is what I meant by "think I can solve it by means discussed > here previously". I think I can see how this would generalize to > additional tables in a DB. I don't think it generalizes to multiple > DBs though, right?
Multiple table yes. Multiple BDs no. > What I was really asking was if there should be a more direct way of > doing this (what I call "sugar")? We can think about it. > It might help if there was better documentation for IS_NOT_IN_DB > because this trick is a little hard (for me at least) to wrap your > head around. The current docstring says: "INPUT > (_type='text',_name='name',requires=IS_NOT_IN_DB(db,db.table))". > > As I understand it this does the moral equivalent of "SELECT > events.name WHERE db.events.competition==request.vars.competition AND > events.name==value" and checks if anything is returned? yes. although it uses count, not select. > On Feb 15, 3:32 pm, mdipierro <[email protected]> wrote: > > > I think you are looking for this: > > > db.events.name.requires=IS_NOT_IN_DB(db > > (db.events.competition==request.vars.competition),'events.name') > > > On Feb 15, 2:20 pm, BigBaaadBob <[email protected]> wrote: > > > > This seems to be a problematic FAQ, but: if I'm making an effort to > > > normalize my database structure how do I do cross-table validation? > > > > Example (with extraneous things left out): > > > > db.define_table('competitions', > > > SQLField('name','string'), > > > SQLField('chief_ref','string')) > > > db.competitions.name.requires=[IS_NOT_EMPTY(), IS_NOT_IN_DB > > > (db,'competitions.name')] > > > > db.define_table('events', > > > SQLField('name','string',length=64), > > > SQLField('competition',db.competitions)) > > > db.events.competition.requires=IS_IN_DB > > > (db,'competitions.id','competitions.name') > > > > I want to assure that newly added events meet the constraint that the > > > combination of events.name+competitions.id is unique. IOW, I don't > > > want two events with the same name for a specific competition. > > > > In this simple case I think I can solve it by means discussed here > > > previously, But still, I would think cross-table validation is a very > > > frequent requirement in real applications that there should be some > > > sugar for it, no? > > > > If you use a carefully normalized schema the number of cross-table > > > validations requirements grows beyond just two. And in real > > > "enterprise" applications, wouldn't you even need to do cross-DB > > > validations? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
