Re: bdbhpt driver - additional data

I believe it should be safe to shove stuff in the dns_zone table's value.  I think DLZ just ignores it.

But, don't put in too much data as it will of course take space in the DB which affects page hit rates.  DLZ may also pull the key back, even though it ignores it.  So making the value large would also cause a performance hit.

Rob



----- Original Message ----
> From: Chris Hastie <[email protected]>
> To: [email protected]
> Sent: Sunday, September 27, 2009 6:31:44 AM
> Subject: Re: [Bind-dlz-testers] bdbhpt driver - additional data
> 
> On 27/09/09 03:20, Scott Haneda wrote:
> > There is no hard in storing any amount of arbitrary data in the same  
> > table as the one in which bind-dlz is looking.  I had at one point a  
> > toggle of "active" that would allow me to turn on and off a zone as as  
> > measure to quickly disable DNS for an entire zone, but not delete it  
> > entirely.
> 
> Thanks Scott.
> 
> This isn't quite what I'm asking though. I'm aware that extra fields can
> be included in the MySQL schema - indeed I have the same 'active' flag
> as you describe. Any old MySQL schema can be used, all that dlz cares
> about is that the query specified returns the correct data in the
> correct order.
> 
> The bddhpt driver is a bit different, and the schema is specific.
> However, the dns_zone table has as a key of the zone name reversed, but
> leaves the value empty. Given that the schema is specific, I'm wondering
> if there is any harm in using this empty value to store the zone's
> serial instead?
> 
> > You can even used stored procedures, and triggers to do more fancy  
> > things.  In the end, I found that I was needing too much MySql power  
> > to keep up with the DNS requests I had coming in, so I went back to a  
> > non DLZ setup, but what you ask is indeed harmless, and you can be  
> > very powerful with what you do in your database.
> 
> A couple of things about the MySQL load. Firstly, when I ran into issues
> with this I found that optimising MySQL's query cache made a huge
> difference.
> 
> Secondly, although in the end motivated by a problem with MySQL
> libraries on 64-bit systems, I've had in mind to do what I'm now doing
> if load on MySQL starts to build too much. I'm retaining the same MySQL
> backend for managing records, but bind-dlz now uses the bdbhpt driver.
> I'm updating the bdbhpt data from the MySQL data.
> 
> Initially I was going to do this periodically from a crontab, and having
> easy access to the latest serial in the bdbhpt data would help do this
> efficiently. But I'm now looking at using triggers, which may do away
> with this need.
> 
> -- 
> Chris Hastie
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Bind-dlz-testers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bind-dlz-testers



      

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf