[eluser]rideearthtom[/eluser]
[quote author="OverZealous" date="1268775433"]@rideearthtom
It's not a bug in DMZ, I'm certain. You've most likely got something configured wrong.
First, it looks like a table prefix being added by CodeIgniter. You can't use CI's prefixes with DMZ - DMZ has it's own prefix management.
Second, the only reason DMZ looks for a join table is if it can't find an ITFK. It only looks for ITFK's on has_one joins (obviously), and the ITFK must be named {relationship_key}_id on the table for the model with the has_one.
The only ITFK I see in your models would be projectexposure_substyles.pe_style_id. If the field is not named exactly that, it won't work.
You might be getting tripped up because your classes have model names that don't match up with the table names.[/quote]
Thanks for the reply Phil.
There are no CI prefixes set up in my app, only the DMZ ones are configured, and in the above models they are overridden by 'projectexposure_' as shown in the code I posted. For this app the DMZ config'd prefixes are are 'tdb_' and 'tdb_join' (hence the generated SQL).
The way I understood your documentation was that it's possible to hardcode the table names into each model's class in order to fix discrepancies, but that this should work for any arbitrary table renaming.
Looking again at the error, it seems that DMZ is looking for a FK column name that matches the model name, not the table name. I.e., in the 'Pe_substyle' model, it's looking for 'pe_style_id' to make the join. But the 'Pe_style' model specifies that the table name is 'styles', not 'pe_styles'.
The manual reads as follows:
Quote:Joining tables must have a specially name id field for each of the tables it is joining, named as the singular of the table name, followed by an underscore (_) and the word id. For example, the joining id field name for table users would be user_id. The joining id field name for table countries would be country_id. This same column name could be used for in-table foreign keys
So unless I missed something fundamental regarding the overriding capabilities of var $table, it looks like there's a discrepancy between the documented behaviour and the actual behaviour. It's funny that I didn't notice this until this week as I've been working on this system with CI and DMZ for several months. Hope that I'm wrong and that the problem lies elsewhere.
Like I said, not too many real-life worries as I can always create the related object with a where clause on the FK column.
The fundamental problem is really this:
I have a database with several sets of prefixed tables, one for each of many applications. There's a central app which has it's own prefix and set of models, but it also needs to work with data from all other apps. I thought it would be as simple as creating more models and overriding the prefixes, but I ran into a problem when I realised that two apps would have different objects with the same name. No problem when designing the db as the prefixes would be different, but in the central app (which works with all the data) I'd end up with multiple models of the same name with different $prefix overrides, which is obviously impossible. So my workaround was to put another prefix on the model name for differentiation (pe_) and override the table name. Maybe there's a more elegant solution...?
