Understanding the drupal tables - drupal

I am reviewing a old system that another developer did with Drupal but i do not understand very well this problem:
There is a node table.
There is another table which it's field_data_field_worker.
field_data_field_worker has a entity_id which makes the relation between node table and field_data_field_worker, that's ok.
There is a node table.
There is another table which it's field_data_field_vacations
field_data_field_vacations has a entity_id which makes the relation between node table and field_data_field_vacations, that's ok.
The problem is that... how i can know this:
When i go to the worker detail, it shows the vacations belong to that worker... but how does Drupal make the relation between the worker and the vacation? because i just see that the unique relation it's node with worker and node with vacation but how Drupal realates worker with vacation? it's not with the node table because... the nodes belong to worker are not same nodes belong to vacation.
Thanks!!

Drupal's database structure is fairly complex so you should make custom queries only if you really need to do that. In all other cases do it "drupalish" way.
Use node_load() function to get whole node object, node_save() (or alternative for D8) to save the node.
For querying multiple nodes use views module.
Point is - you don't have to understand Drupal's database structure - it's under the hood. Use the tools Drupal provides to work with database.

Related

AX 2009: Can't find "SalesCreateReleaseOrderLineTmp" Table

I am a beginner in AX and I am trying to set access rights for some users and on a specific operation they get the error that they don't have access to the table SalesCreateReleaseOrderLineTmp. I have manually searched for this table in every category, but without success. I found on a website the full description of this table -> Order Lines - SalesCreateReleaseOrderLineTmp - ID: 995. I've search for the ID as well, but again no result. With admin rights everything is ok, but obviously not a solution.
Is there a fix location of this table and can anyone tell me where it is? :) Or is there any way to search for this table (by ID or name)?
I guess with
I have manually searched for this table in every category, but without
success
you mean you tried to find the table in the form for maintaining the user group permissions?
If so then this is due to the fact that temporary tables are hidden from that tree view as the class method SysDictTable.allowSecuritySetup is called from SysSecurity.expandSecurityKey while building the tree view and in this method there is - among other things - a check whether the table is temporary.
So essentially you have 3 options:
Give your permission group the desired access on the security key so that the group 'inherits' access to the table through it - downside of course could be to be too permissive but upside is better maintainability :)
Remove the security key on the temporary table as this in general is IMHO a wrong decision anyway. The application shouldn't restrict access to temporary tables (which are intrinsically scoped to the user session anyway) but rather force access checks in the code filling that table or even higher level processes.
Customize the code which builds the security tree view so that it includes temp. tables.
Try to apply the first option above that works for you as the first one does not need any application modification and the second one is only a simple property change which in my opinion is currently bad configured anyway. The last option should be the last resort.

How to handle large quantities of inter-related data

Currently I have a DB structure in MySQL with a few dozen tables with various foreign key linkages among them. All of the data is in files that I'm going to load in, so I'm hoping I can port the design over to a storage system that works with Drupal 7, since I can simply setup something (using the Feeds module?) to get my data in a way that Drupal 7 likes. The ultimate purpose of this is for lots of manual human revision, linking together entries in tables with relations and possibly revising some field data that looks wrong. So the whole goal is to make the human interface for viewing and editing (particularly adding) relations in Drupal 7. The question is, what is the proper way for the data to be stored so I have to write as little module code as needed?
It seems to me that I would choose one of 3 modules to accomplish this task:
Relation
Entity Reference
Data
Relation and Entity Reference would allow me to store all of my data in nodes (entities?) in Drupal 7, so Drupal would have "native support" for handling all of the stuff. However, I expect there to be 100s of millions to low billions of nodes with perhaps up to ~3 relations to other nodes in each. How efficiently does Relation or Entity Reference handle this when referencing foreign data (and perhaps grabbing referenced data from that reference, and so on) with Views and the like? Can they support a node having a null reference, since many will be null until a user can set them (so I'd need a way to also have a view to find nodes with particular null references)?
Data is another possibility, but it's in alpha and I wonder about its stability and efficiency. It also seems to me that having all of my data stored in an external MySQL database instead of in Drupal nodes defeats the entire purpose of using Drupal in the first place. Is my feeling on this correct?
I'm having a difficult time nailing down what I would need to manage my content, which seems odd considering Drupal 7 is a CMS. I have to be missing something here, but I'm not sure what it is. What is the most mature module(s?) for handling/interfacing with this large quantity of inter-related data and being able to go through and have a user mostly setting up and managing the links (so "foreign keys") between "tables", along with perhaps field data review and revision? Are there any that would suffice?
Relation and Entity Reference would allow me to store all of my data
in nodes (entities?) in Drupal 7, so Drupal would have "native
support" for handling all of the stuff. However, I expect there to be
100s of millions to low billions of nodes with perhaps up to ~3
relations to other nodes in each. How efficiently does Relation or
Entity Reference handle this when referencing foreign data (and
perhaps grabbing referenced data from that reference, and so on) with
Views and the like?
If your need the Data to display, another model will not help you. You might need some Pagination or give your query an maximum depth of recursion to load only the entities you are interested in. I guess using something that is already supported will save you a lot of work.
Without benchmarks you can barely find your bottlenecks. So go the easiest way which seems to be the Entity References and optimize as needed. You can create some test data to find limitations early. But there will be ways to optimize the requests later for sure.

Dynamic SiteMap, BreadCrumb Based Off of Multiple Tables

I have about 20 different tables that each have a different parent / child relationship built into them. I've recently been asked to create a breadcrumb and Site Map for our website based off of all of these tables.
One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId and whenever I need to pull the parent child relationship I would just join the parent_child_relationships table to whatever table I was pulling from specifically.
Does this make sense?
Anyway, the problem with this idea is that i don't like it. haha.
Does anyone else have any other ideas of how this could be done? Or what the correct way of building a breadcrumb and sitemap based off of a site comprised of 20 tables or so?
If it helps, my site is comprised of asp.net, ColdFusion and uses a MSSQL database.
Thanks!
Do not let the implementation of the UI effect the design of your model and especially not your DB. Prototype the front end, involve your customer(s), give them a voice. Build your breadcrumbs and site map without it initially tied into your actual DB. Once your customer says "thats what we want, just like that", then freeze the prototype, then work on the actual implementation - how will your app request the data, what type of dataobject will you use AND THEN build your db,
"One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId"
This is not a very scalable solution, do not *reverse normalize your db. Follow standard relation database modeling/normalization techniques. Lots of small cohensive tables with lots of association tables.

Drupal: Upgrade Node strategy

I effectively want two nodes:
Normal Node
Premium Node
The only difference will be that the premium node can take more images and a few other features. What is the best strategy to go about this?
have two distinct nodes with the differences
have one nodes and somehow find a to apply an UPGRADED attribute to it?
I would prefer (b), as I want users to be able to upgrade nodes. And migrating a normal node to a premium node will be very difficult.
Any idea how I can accomplish b?
I would create two different content types (CCK), and either write custom code to translate between the two or use a module like Node Convert (in order to upgrade a node); it might be complicated at first, but you would have the advantage of being able to apply all of your restrictions (allowed image count, permissions etc) on a per-content type basis.
Here is an excerpt from the Node Convert project page:
... adds a menu tab "Convert" on the node view page, i.e. node/1/convert, which gives the ability to convert the node from its current node type to another node type. The module provides the means to transfer all the field values of the current node type into fields on the destination node type, or discard them.
The module integrates with Actions, Rules, Views Bulk Operations and Admin Views nicely. It has support for exporting templates into Features using CTools Exportables. It also provides a hook that enables developers to execute additional code on conversion.
You might be able to implement (b) as two different input filters - one for non-upgraded and one for upgraded. Then "upgrading" the node would be as simple as changing the input filter applied to its contents.

Batch node operations in Drupal 5

What is the most efficient way to go through and update every single node in a drupal site, to, for instance mechanically add tags? Drupal 6 has a shiny new batch API, but what to do in Drupal 5?
I started writing a script that keeps a pointer and then goes around all nodes on a cron, loads them and then saves them, but I wonder what else could be done.
I don't suggest working directly on the database level since some modules might want to update some other related tables. The most reliable and flexible way is to write a script to load, change and save nodes in a loop. You can also try using additional special modules for Drupal 5:
Taxonomy Node Operations
Taxonomy Multi Editor (similar functionality)
and more general module Views Bulk Operations
Consider the Job queue module. Here is a quote about it (from the module's project page):
... used by modules to queue function calls for execution on cron. The job_queue_add() function is used by modules to add a job to the queue
This module is end of life for Drupal 7, there is a queue in core.
hmm i'm not familiar with drupal 5's database structure, but if it's similar enough to drupal 6, you could just modify this all pretty easily by just working off the term_node table. it's a mapper of node id's to term id's:
term_node
- nid
- vid
- tid
nid is the node id of course, vid is the revision id, if you use revisions, and tid is the term id. terms are all stored in term_data
term_data
- tid
- name
are the more interesting columns. so if you already have existing terms, you can create a quick map of existing tid's, then add to whatever nodes you want in term_node. anyhow, being careless in this regard could possibly cause weird data issues, so i wouldn't suggest this approach unless you feel pretty comfortable with the raw database.

Resources