-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
load table maps lazily #1902
load table maps lazily #1902
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1902 +/- ##
============================================
+ Coverage 87.61% 87.64% +0.02%
- Complexity 7818 7826 +8
============================================
Files 227 227
Lines 21161 21180 +19
============================================
+ Hits 18540 18563 +23
+ Misses 2621 2617 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
a0df3bb
to
b64f3dd
Compare
508520c
to
3646296
Compare
3646296
to
26eea73
Compare
b045f1f
to
09df751
Compare
Local testing with 350 tables: |
fixes #1901
When adding table classes to a Propel database object, currently those classes are immediately instantiated, event though many of those classes will not be used in one cycle, leading to unnecessary overhead, particularly on databases with lots of tables.
A simple fix is to add tables as class strings, and only instantiate them when they are actually used.
The way it is implemented here, the
$tables
and$tablesByPhpName
properties of DatabaseMap now can contain both TableMap objects or class strings, which is not ideal, but it seems to be the most seamless integration of this change. Let me know if there is a better way.