1 of 62 1 2 3 Next Last

DMZ 1.7.1 (DataMapper OverZealous Edition)
 Posted: 16 March 2010 06:41 PM [ # 11 ]   [ Rating: 0 ]
Joined: 2008-10-08
1039 posts

@Jack Scott

Well, you are calling _assign_libraries in your own code somewhere, apparently the Rem4_property_file

That function is only accessed by DMZ internally.  That’s why it has been made protected.  None of the methods that start with an underscore are publicly-accessible (and they never have been).

Search your code for that function.  It shouldn’t be used outside the DMZ source.  You probably should just remove that method call altogether, where-ever you find it.  There are actually quite a few methods that have been removed from public access.

This was documented in the upgrade instructions.

Edit:
I want to clarify the sentence above: I mean that none of the underscore methods have been documented and supported for use outside of the core library.  In other words, they aren’t part of the DMZ API, so they shouldn’t be called directly.

Technically, they have been “public” before now, but that’s because I only just recently decided to add visibility modifiers to the methods and properties.

Signature

Phil DeJarnett
OverZealous Creations, LLC

 Posted: 17 March 2010 02:35 AM [ # 12 ]   [ Rating: 0 ]
Joined: 2009-12-16
24 posts
OverZealous - 16 March 2010 05:37 PM

@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.

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:

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…?

 Posted: 17 March 2010 06:56 AM [ # 13 ]   [ Rating: 0 ]
Joined: 2008-10-15
147 posts

Great! I’ll upload my project with that new version and see if it works smoothly. Great job! Can’t wait to test it.

 Posted: 17 March 2010 12:05 PM [ # 14 ]   [ Rating: 0 ]
Joined: 2008-10-08
1039 posts
rideearthtom - 17 March 2010 06:35 AM

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’.

It is (slightly) incorrectly documented.  (A lot of the documentation is a mix of old DataMapper and new DMZ, so some of it isn’t perfect.)

DMZ uses the $table->model field when generating the ITFK name. The biggest reason for the difference in the docs is that$table is supposed to be the plural form of the model.  The real purpose of the override is for table names with unusual pluralization.

This is the exact quote on tables from the manual:

Normal tables must be named the lowercase, pluralised version of the object name. So for a user object of User, the table would be named users. For Country, it would be countries. (For odd pluralizations, you may need to hard code the $table or$model fields.)

So, it’s not intended that you would have arbitrary table names.  However, it should work in your case, just rename the ITFK column correctly.

It’s not really a bug, just that you are using the application a bit outside it’s intended design.

Signature

Phil DeJarnett
OverZealous Creations, LLC

 Posted: 17 March 2010 05:58 PM [ # 15 ]   [ Rating: 0 ]
Joined: 2009-06-18
279 posts

Still getting this:

 Parse error: syntax error, unexpected $end in D:\xampplite\htdocs\em\system\application\controllers\admin.php on line 198  Line 198 contains only } Usually this is because of an unclosed tag, but now…  Posted: 17 March 2010 06:10 PM [ # 16 ] [ Rating: 0 ] Joined: 2008-10-08 1039 posts Mareshal - 17 March 2010 09:58 PM  Parse error: syntax error, unexpected$end in D:\xampplite\htdocs\em\system\application\controllers\admin.php on line 198  

That means the error is in your code.  If the error was related to DMZ, it would mention one of the DMZ files.

A parse error basically means a typo.

Run this on the command line to see that it is your file:

 php -l D:\xampplite\htdocs\em\system\application\controllers\admin.php  

(This assumes PHP is a global executable.)

Signature

Phil DeJarnett
OverZealous Creations, LLC

 Posted: 17 March 2010 06:12 PM [ # 17 ]   [ Rating: 0 ]
Joined: 2009-06-18
279 posts

Actually is your example from rar

 Posted: 17 March 2010 06:15 PM [ # 18 ]   [ Rating: 0 ]
Joined: 2009-12-15
35 posts

@Jack Scott, OverZealous

It broke with a
Fatal error: Uncaught exception ‘Exception’ with message ‘Unable to call the method “_assign_libraries” on the class Rem4_property_file’

To offer an alternative to what Phil said, I believe the problem is that you’re loading the class via CI’s Loader, which calls _assign_libraries. If you follow the DMZ way of not calling load->model and just do a “new Whatever()” you shouldn’t run into that problem.

On a side note, I don’t see why you’d really need to auto-load related models in your model’s constructor, because accessing the related variable, e.g. “\$user->group” will auto-load the related class anyway.  That’s just part of DMZ.  And if you wanted the model in your controller, instantiating a DMZ model (as in the above paragraph) auto-loads as well.  So maybe you have some reason for doing so, but I’d guess that you’re going about it the hard way and that extension to the constructor isn’t necessary.

Letting the built-in lazy loading of related classes do its thing rather than loading all related classes whenever one is instantiated is bound to have some performance benefit too, possibly significant if you’ve got a bunch of classes all related to each other.

 Posted: 17 March 2010 06:19 PM [ # 19 ]   [ Rating: 0 ]
Joined: 2008-10-08
1039 posts
Mareshal - 17 March 2010 10:12 PM

Actually is your example from rar

By example, you mean the example app, or examples in the docs?

I just tried the example application, completely resetting it, and never saw the error.  There might be a typo in the docs, however.

Signature

Phil DeJarnett
OverZealous Creations, LLC

 Posted: 17 March 2010 06:24 PM [ # 20 ]   [ Rating: 0 ]
Joined: 2009-06-18
279 posts

I just cloned the CI from bitbucket, copied the example from archive into /system overwriting everything

download my code from here:

 http://dl.transfer.ro/em-transfer_RO-17mar-86edf3.rar  
 Posted: 17 March 2010 06:28 PM [ # 21 ]   [ Rating: 0 ]
Joined: 2008-10-08
1039 posts
TheJim - 17 March 2010 10:15 PM

To offer an alternative to what Phil said, I believe the problem is that you’re loading the class via CI’s Loader, which calls _assign_libraries. If you follow the DMZ way of not calling load->model and just do a “new Whatever()” you shouldn’t run into that problem.

Good call.  I actually didn’t know that CodeIgniter calls _assign_libraries on models.

I’ll have to think about what to do.  It’s actually kinda bad to use Loader::model(), since DMZ specifically says don’t do it.

I might rename _assign_libraries (like, _assign_libraries_private), then use the original method to throw an error when models get loaded manually.  This will prevent DMZ models from being loaded by CI.

Or, I could just let CI load the model, but there’s no telling if that would be a problem or not.

I’ll think about it.

Signature

Phil DeJarnett
OverZealous Creations, LLC

 Posted: 17 March 2010 06:32 PM [ # 22 ]   [ Rating: 0 ]
Joined: 2010-03-12
3 posts

Just updated to 1.7 and I apparently have that same error. :(

ok found out why, I don’t need to load models at all !

Not in autoload, neither in the controller. It work with magic.

 Posted: 17 March 2010 06:32 PM [ # 23 ]   [ Rating: 0 ]
Joined: 2009-06-18
279 posts

OverZealous, did you download my archive?

 Posted: 17 March 2010 06:34 PM [ # 24 ]   [ Rating: 0 ]
Joined: 2008-10-08
1039 posts

@Mareshal
I don’t know what to tell you.  It’s not DMZ — there’s no parse errors with the source for the admin.php file.  It hasn’t been changed since 8/25/2009 (I can see it in the repository).

I just double-checked the ZIP, too, it’s OK there.

Maybe that file is corrupted on your copy?

Signature

Phil DeJarnett
OverZealous Creations, LLC

 Posted: 17 March 2010 06:37 PM [ # 25 ]   [ Rating: 0 ]
Joined: 2008-10-08
1039 posts

FOR ALL THOSE WITH THE _assign_libraries ERROR

Remove all the models from autoload, just as it says in the installation manual.

Double-checking your installation is the first step in the troubleshooting document.

Signature

Phil DeJarnett
OverZealous Creations, LLC

 1 of 62 1 2 3 Next Last