0

I have a bunch of DNS records in a table, where the "type" column defines the type of the given record.

I would like to have a class hierarchy of models in Lithium representing these records such as:

RR - base resource record (abstract - sort of)  
RR_SOA - SOA record, extends RR  
RR_CNAME - CNAME record, extends RR  
...  etc ...

So one class for each record, all mapping to the same table.

Next I would like to use RR::find which would automagically give me a list of objects where the class of each object corresponds to the type of the actual record.

Is this even possible without too much black magic?

Jared Farrish
  • 48,585
  • 17
  • 95
  • 104
Csongor Fagyal
  • 514
  • 2
  • 10
  • So 1 class per record (in terms of the table)? – Matt Lo Jul 30 '12 at 01:58
  • E.g. type=CNAME content=foo.com type=SOA content=xyz324 type=CNAME content=bar.com RR::find('all') shold give array(instance1 of RR_CNAME, instance 1 of RR_SOA, instance 2 of RR_CNAME) – Csongor Fagyal Jul 30 '12 at 02:03

1 Answers1

1

Yes (anything is possible) but you're approach may be too ambitious. In my POV, I would depend on @class RR to handle the basic querying of the target table, but by utilizing filters on RR (specifically on the find method inherited from Model), you can pass-by-reference the instance to sets of newly instantiated classes (SOA, CNAME, etc...) along with their position in the table (so SOA object is only associated with that specific record or primary key).

There is some black magic going on, but nothing the Lithium core developers didn't account for.

Bottom line, 1 base class for your table (RR model), multiple (possibly inherited from another base unrelated to Model) for SOA, CNAME, etc..., and a filter (put anywhere really) to intervene RR::find and/or the late binded RR::findby*

Does this make sense?

(This will require some trial and error. First to see if you can manipulate the data output, after that the rest is butter)

Matt Lo
  • 5,442
  • 1
  • 21
  • 21
  • It does make sense, but I find using filters in this case a bit of a hackery. Filters are extremely powerful in Lithium, but it worries me that they put some important logic at a "remote location". If I open RR_SOA, for example, I would really like to see the logic right there, and not get surprised later on as some misc/ code overrides its behavior. It's totally different with e.g. logging, which does not interfere with my logic, but in this case it's just "too much". It feels like "I can't do this properly, so lets do this instead" :) – Csongor Fagyal Jul 30 '12 at 10:34