I am new to the Moodle world. I want to make inner join 2 or more tables with PDO. I checked documentation but can't find anything helpful. Maybe I am missing some part of Moodle. Let's say I want to get all users enrolled to the specified course.
Is there any way to make something similar to this:
$users = get_records(['course', 'user'], 'course.id = user.course_id');
I got replied from Moodle forum:
No.
The DB API is there to simplify many common situations (e.g. getting
one or more records from a single table), but if you need to gather
data from more than one table at once, then you need to use
$DB->get_records_sql() (or similar).
However, if you want a list of users in a particular course, then use
the get_enrolled_users() function, rather than trying to manually
write the SQL query for it.
Related
I've a database which updates very frequently and I would like solr to synchronise it automatically.
I've 20+ tables but I want my search should be work in only 2 tables and only in some specific field only.
I've put some data manually in solr and run it with get api.
http://127.0.0.1:8983/solr/gettingstarted/select?indent=on&q=:&wt=json
and it works perfectly fine.
can we also do something like if my 'X' users search somethings and in another table I'll check that if post is made by 'X' and his friends then only returns that otherwise not I mean can we get data with conditions as well ?
Please provide some link or resource or any related reference or solution regarding it.
TIA
There is no automagic syncing in Solr. You'll either have to send the updates to Solr yourself (through the regular POST interface), or trigger a deltaimport through the DataImportHandler if that's what you're using.
For your second case - the answer depends - but the most straight forward way is to include a list of valid usernames or user_ids in your query and then filter against that list (in a fq=posted_by:(foo OR bar OR baz OR ...). This is limited by the number of boolean clauses in your solrconfig.
So, the context is: I have a site in which many pages may need the information about one table, say for instance, 'films'. This table has many fields, like title, language, year, description, director... And perhaps in one page I need only the title and the id of some rows and in another I also need the description.
So the question is: should I code a database manager (I am using MySQL) that retrieves all the fields of the rows that satisfy a condition (I guess the WHERE clause should be passed as a parameter)? Or should I be able to specify which fields are needed? I thinks this cannot be done easily with mysqli (because prepared statements require to specify beforehand the number of fetched fields), so for this to work I would need to use PDO instead, which I haven't used yet. Is it worth it this last approach? Or there is not really a big difference in performance if I retrieve the whole information about those rows?
Thank you in advance.
Based upon the comments above, My answer to your question(s) is
Retrieving some fields vs all fields isn't a real performance consideration until you are dealing with one or more CLOB/TEXT columns which have a lot of text in them. Good database practice indicates you should always specify which fields are returned from a query.
Any query against any table should have a where clause to restrict the number of rows returned. Especially if you are looking to query exactly one row.
Your question implies you are writing a wrapper layer around the queries to hide this complexity. Don't do this. Get an existing PHP library that does this work for you. See for example: Good PHP ORM Library? . There are a number of subtle issues, like security, which you will overlook.
Apologies in advance for the wall of text; not sure if this is possible but i thought i'd ask. I've looked online and can't quite find what i want. I have been learning a lot of PHP and MySQL and am at the stage where i am starting to write my own database driven websites. A freely available database i have been practicing with is the eve_sdd_crucible_11 database which is freely available from the game website. I have been using it because it's huge and requires the use of a lot of different skills to get the most out of it.
I would like to do a simple database for exploration. This database queries the main one for information, creates a new table based on the search results and also allows the user to add their own comments on what they have found. I have the various queries ready to go but because i don't want a massive user interface, i want to keep the user side as clean as possible. This app needs to query and display results from the 'mapregions', 'mapconstellations', 'mapsolarsystems' and 'mapdenormalize' tables and insert this information into a new database with the retrieved info plus a comment box for each entity.
Now the preamble is done, this is what i am looking to do:
Query 'mapregions' (region name returns region ID to be used in next query) and display results (linked)->
click on linked result, query 'mapconstellations' (constellation name returns constellation ID to be used in next query) and display results (linked)->
click on linked result, query 'mapsolarsystems' (solar system name returns solar system ID to be used in next query) and display results (linked) ->
click on linked result, query 'mapdenormalise' and display all entities in that system -> Inject content into new database along with comment boxes per listed entity.
Like i said earlier in the post, i have the queries set up ready to go, i have the beginnings of the php for the page but i am stuck on how to link these displayed results to the next query in the chain. All results have to display the name of the entity and it's the entity's corresponding ID number that is used to execute the next query in the chain.
Not sure if i've explained it particularly well, but it's the best i can do at this time of night... Any help or pointers would be vastly appreciated as it's starting to do my head in ;)
Need to look into joins - from reading through that text, it seems like you're missing a basic understanding of how to join tables - your 4th paragraph, to me, sounds like it should be a single query.
Creating a new database and/or table per search shows that you might still be missing some of the fundamentals - as that approach would never scale and would be a nightmare to manage.
Start reading up on mysql joins: Mysql Joins and go from there, looking at other examples of how joins work and real world examples - that will hugely affect how you continue building this.
I am writing an app in cakephp that will perform scheduled searches for users and store the search results in a matches table. My question is do I really need this matches model in cakephp to store the results? If the answer is no, how should I store the results?
Happy new year.
There are many ways to store data and the one you choose will depend on the data itself and the use to which it will be put (and when it will be used). Because you are doing scheduled searches, I assume that the user may not be around when the search is done, in which case the result needs to be stored.
In this case, I'd use the database. If you need to keep historical results this is definitely the way to go. If the results can be overwritten, you could use a text file per user, but that might get messy.
You don't need to use the main database - you could have another MySql, for example or even a totally different one such as a flat file db.
What would I do? I'd use a table in the main database and get on with something else.
I have a CakePHP application where I am trying to get a count of how many of each type of post a user has. I am also using the paginate helper to display all the user's posts on their profile.
I could:
1) Make a find('all', $conditions) request for all the user's posts then parse that for the counts I need (by going post by post and checking if it matches what I'm looking for).
2) Make multiplie find('count', $conditions) requests, getting all the counts I need individually.
3) Maintain new columns in the user's table to track these numbers when the posts are created (put that would involve writing to the user account whenever a new post is made).
Which one would be the best choice?
Fetching all records from the database and counting them in PHP is hugely wasteful nonsense. That's exactly what databases are for.
A find('count') just makes an SQL query like SELECT COUNT(*) FROM … WHERE …, which is really the fastest way to go. Add appropriate conditions to get the count you want, you may need to brush up on your SQL to know what conditions these are.
There's also the special of counter-caching, which you might want to look into if you're counting hasMany relations.
You should modify your find call to include a group by condition to aggregate the count by type. See here for more info: http://debuggable.com/posts/how-to-group-by-in-cakephps-new-release-part-2:4850d2c9-edbc-4f0e-9e0e-07d64834cda3