Directly adding string
handlers.inc:1460
extra: An array of extra conditions on the join. Each condition is either a string that's directly added(...)
Well, I tried it. Join definition:
$data['series_has_language']['table']['join']['brand'] = array(
'left_table' => 'series',
'left_field' => 'idSeries',
'field' => 'idSeries',
'extra' => array(
'brand_has_language' => 'directly added string', //'brand_has_language.idLanguage = series_has_language.idLanguage',
),
);Result:
LEFT JOIN {series_has_language} series_has_language ON series.idSeries = series_has_language.idSeries AND series_has_language.d = 'd'
Both bolded letters are always the first letters of my string.
"Numeric" ignored
handlers.inc:1470
numeric: If true, the value will not be surrounded in quotes.
Long story short, it is surrounded no matter how I set it or not.
Making at least one work
I tried to write a patch for the second (if around quotes sounded so easy) but failed miserably. With custom string approach I'm not sure where to begin. My bet is around line 1549 foreach ($this->extra as $info) { , I see $info never tested for being an array or string or anything else. Testing will be simple. Passing it down the line may get a bit more tricky.
| Comment | File | Size | Author |
|---|---|---|---|
| #35 | mymodule_handler_join.inc_.do-not-test.patch | 4.18 KB | bdimaggio |
| #17 | handlers_join_handler_1966648-17.patch | 5.96 KB | Mołot |
| #8 | handlers_join_handler.patch | 5.96 KB | Mołot |
| #4 | handlers_join_handler.patch | 6.15 KB | Mołot |
| #3 | handlers.inc_.patch | 846 bytes | Mołot |
Comments
Comment #1
merlinofchaos commentedHm. With the changeover to PDO, the 'numeric' setting is probably obsolete.
I'm not sure about the raw string. Clearly that's not working, and it's possible that functionality was removed. A patch to add it in might be fine. Note that what you're doing with it is probably fairly dangerous as the table names like you have can't be guaranteed, so I'm not sure it will work in any case.
I think that for what you're trying to do, you'll probably need a custom join handler; views_join can't handle trying to put in table names, I'm afraid. Sorry about that.
Comment #2
Mołot commentedWell, if you feel these options should not be there, we might change Component of this issue to "Documentation".
Being unable to use extras to connect two tables by additional fields makes all "extra" functionality obsolete. Now the only use of it is to add hardcoded filter in join instead of where - pointless.
For hardcoded strings - would support for {} be any help? I admit it will not be in first version of my patch if I'll get to make it, but that's something to think about, I guess.
Comment #3
Mołot commentedPatch to fix "numeric" line
Comment #4
Mołot commentedOK, I have patch for custom added strings. It does NOT support {} yet, it seems, but anyway it's better than nothing. If someone want to insert custom SQL parts in his module, I think we may assume he knows what he's doing.
For modules that are going to get distributet use of this should be discouraged of course, but for prototyping and for single-client single-purpose cases I see no reasons to disable it. And either way, it should work as advertised or not be advertised at all if it's not going to work anymore.
PS dunno why my patch looks weird. Machine-generated stuff. But it applies OK for me.
Comment #6
Mołot commented#4: handlers_join_handler.patch queued for re-testing.
Comment #8
Mołot commentedTrying to fix patch
Comment #9
Mołot commentedComment #10
Mołot commented#3: handlers.inc_.patch queued for re-testing.
Comment #12
Mołot commentedOK, I give up. Can someboty tell me how to make a patch that will be accepted? fatal: corrupt patch at line last line of file isn't particulary helpful.
Comment #13
merlinofchaos commentedVisually your patch looks right, so I don't know why the patch is failing. :( Maybe testbot is in a bad mood.
Comment #14
Mołot commentedOK, I'll try again in a few days.
Or would you be so kind and re-generate it on your machine? It may be the case I'm on windows here, my linux machine broke (quite literally) some time ago so I hardly can go native.
Comment #15
Mołot commented#8: handlers_join_handler.patch queued for re-testing.
Comment #17
Mołot commentedone more shot?
Comment #19
Mołot commented#17: handlers_join_handler_1966648-17.patch queued for re-testing.
Comment #21
Mołot commented#17: handlers_join_handler_1966648-17.patch queued for re-testing.
Comment #22
Mołot commentedOK, friend of mine noticed I somehow lost endline at the end of file. So I'm attaching fixed version, but now I only get "Repository checkout: failed to create dependency directory."
I love idea behind testbot, but somehow hate how it currently works.
Comment #23
Mołot commentedTestbot finally accepted this patch. Waiting for community or developer's input.
Patch from #17 marks 'numeric' as deprecated in docs, and makes 'directly added string' to work as advertised. As I see it - future patches might and probably should make aliases work in strings, but that's not essential as this feature is mostly for single-client cases anyway.
Comment #24
Mołot commentedComment #25
Mołot commentedBump.
Will this make it to the next release? Or is any other solution for this bug prepared?
Comment #26
Mołot commentedBump
So I found a bug, got confirmation that things works differently than documented in code, made a patch that fix what can be fixed and clarifies what cannot be fixed...
Is there anything more I could to to get that bug fixed once and for all? One way or another?
Comment #27
Mołot commentedI forgot to tag it as regression - it once worked all right, t does not now.
Comment #28
macsim commentedSubscribing !
I need to alter a view query to add a specific INNER JOIN with 3 conditions and there's no way to do it following the views_join doc because it doesn't work as expected !
As you can see in the comments, the generated join miss an "AND" between these 2 conditions and about the conditions... well... should I speak about that ??? It's not what I was expecting !
Then I tried this one :
Still need an "AND" between these 2 conditions and even giving numeric = 1, there are simple quotes around the values ! That sucks !! It was almost good ><
I don't know how to achieve this... If someone has an idea, feel free to share it !
Thanks
Comment #29
Mołot commented@MacSim Tried #17 patch and "string" approach?
Comment #30
macsim commentednot yet as you were saying in #27 that it wasn't working anymore... but maybe you were speaking about something else ?
I am going to try it ;)
Comment #31
macsim commentedWell there was still no AND between my two "string" conditions so I made a unique string with these 2 conditions inside and thanks to your patch I now have the query I wanted !
Congrats !
Comment #32
Mołot commentedI meant that this functionality existed back in previous versions. Patch still applies cleanly as far as I know.
Sorry, I wasn't able to restore "numeric" option. Or rather maybe I would be able to, but I found it to complicated to be worth it. See #1. At least when maintainers seems to ignore this issue now - last post April 11. Guess they don't need it and are to busy. To bad as I think I provided working, if partial, solution ready to drop in.
Comment #32.0
Mołot commentedcode -> blockquote as was not working in code
Comment #33
bdimaggioI took Mołot's idea and just extended the views_join handler in order to accommodate this functionality. That way there's no need to patch Views. Once you've added the attached to your module's "views" subdirectory, you can create a new join as suggested in this comment, only replacing
with
...and
with
Hope that helps!
Comment #34
dawehnerOh ... this sounds like a nogo, why would you do an API change which might break other people's code.
@bdimaggio
Great suggestion!
Comment #35
bdimaggioOops. Didn't realize that my "mymodule.views.inc" failed to upload, cause d.o doesn't accept .inc files. I've disguised it as a .patch here--to use, rename as "[module name]_handler_join.inc".