I've been using cakephp for a while, but have not learned all the ins and outs yet so I may be missing something simple. Or the problem may lie with my database structure. Either way, if anyone has any idea of what I'm doing wrong, please share.
Is there a way to order the data returned by cakephp's find using values stored in another table?
I am creating custom form fields on a per category basis, so when I choose a particular category to post in, custom fields will be added to my form. I have 3 tables: Posts, Fields, and Answers. The Posts table stores the basic static information for the post, such as id, category_id, title, and description. The Fields table stores the custom field data, such as category_id, field_label, field size, etc. The Answers table stores the values that are entered for particular fields, such as post_id, field_id, value.
I am trying to display the posts for a particular category, and create html table headers on the fly, using select fields, set by a column toggle in the fields table, and also select the answers associated with that particular field and post.
I am able to select all the data I want, and paginate everything just fine, but what I can't seem to figure out is how to order the data using one of the dynamic column values. For example, if I have year, make, and model as 3 custom fields, I would like to click the year column to sort my results by the year values, and if I click the make column, I would like to sort my results by the make values, etc.
I know how to order the results by a particular field inside the posts table, such as id or title, but is it possible to order using the custom fields? Am I setting up the database and/or something else wrong, and if not is there are particular cakephp method or sql command that I need to use in order to sort by the custom fields? I'm not really well versed in complex sql commands.
Thanks.
I'd suggest you pass the field name and sort direction in the URL (GET param). So when you have your table header link, form it so that it links to a URL as so:
http://somesite.com/pages/index/sort:customfield1/dir:asc
Then when you're grabbing the data from the db in your find() query, include the named parameters as the order parameter that can be sent to find.
You'll need to determine a default sorting column and direction. Maybe have that be selectable with a boolean field in the schema -- if there are no parameters sent to the action above, pull the field from your other table that has default set to true in the record.
To clarify: when a user visits a given action, first you'll pull the custom fields from the other table. Then using those fields (either the default as mentioned above, or the named params passed in the URL) form the query for the actual data, using the order parameter.
Related
I have seen the link below which explains that it is possible to create a filter on one field between sources by generating a calculated field and then assigning the same field ID to both fields for filtering purposes:
Using the same filter control for two different data sources
But my question is whether or not it is possible to make that particular field (that is now shared between 2 data sources) dependent on other filters that are tied to 1 of the data sources?
Example would be:
One dataset with country name and city name
One dataset with city name and population
I've generated a calculated field to be able to filter on city name since they now share the same field_id.
What I'd like to do is use a control that selects country from dataset 1 and then automatically filters city_name in both datasets.
I realize I could just pull country name into my dataset in the example above, but in my real dataset there are a significant number of fields I'd be looking to be able to use for filters.
If a filter is set, all charts and filters are updated with that setting. However, it would be a huge mess, if any of these objects would automatically changes the filters again. Then all object would be updated again and the filter setting could be changed once more, thus ending up in an infinity loop.
Therefore, a filter can only apply to a field. If this should cause further filtering an user action is needed. It would be possible to write a customer vizualisation, which would mimic an user action, but again it could end in an infinity loop.
I'm in the process of writing a SuiteTalk integration, and I've hit an interesting data transformation issue. In the target system, we have a sort of notes table which has a category column and then the notes column. Data going into that table from NetSuite could be several different fields on a single entity in NetSuite terms, but several records of different categories in our terms.
If you take the example of a Sales Order, you might have two text fields that we need to bring across as notes. For each of those fields I need to create a row, with both the notes field in the same column but separate rows. This would allow me to add a dynamic column that give the category for each of those fields.
So instead of
SO number notes 1 notes 2
SO1234567 some text1 some text2
You’d get
SO Number Category Text
SO1234567 category 1 some text1
SO1234567 category 2 some text2
The two problems I’m really trying to solve here are:
Where can I store the category name? It can’t be the field name in NetSuite. It needs to be configurable per customer as the number of notes fields in each record type might vary across implementations. This is currently my main blocker.
Performance – I could create a saved search for each type of note, and bring one row across each time, but that’s not really an acceptable performance hit if I can do it all in one call.
I use Saved Searches in NetSuite to provide a configurable way of filtering the data to import into the target system.
If I were writing a SQL query, i would use the UNION clause, with the first column being a dynamic column denoting the category and the second column being the actual data field from NetSuite. My ideal would be if I could somehow do a similar thing either as a single saved search, or as one saved search per entity, without having to create any additional fields within NetSuite itself, so that from the SuiteTalk side I can just query the search and pull in the data.
As a temporary kludge, I now have multiple saved searches in NetSuite, one per category, and within the ID of the saved search I expect the category name and an indicator of the record type. I then have a parent search which gives me the searches for that record type - it's very clunky, and ultimately results in far too many round trips for me to be satisfied.
Any idea if something like this is at all possible?? Or if not, is there a way of solving this without hard-coding the category values in the front end? Even if I can bring back multiple recordsets in one call, that would be a performance enhancement.
I've asked the same question on the NetSuite forums but to no avail.
Thanks
At first read it sounds like you are trying to query a set of fields from entities. The fields may be custom fields or built in fields. Can you not just query the entities where your saved search has all the potential category columns and then transform the received data into categories?
Otherwise please provide more specifics in Netsuite terms about what you are trying to do.
Note: I'm working with a large complex database, so for clarity's sake I have simplified the set up below.
I struggled a bit with how to title the question since it's a bit of a complex question. I hope it's accurate enough....
A bit of background first:
I have an Access 2010 database that contains a one-to-many relationship between a table Called "Products" and a table called "Datasets" (ie I have a bunch of products, and each product has multiple datasets). Each has an autonumber key field (p_ID and d_ID respectively) as well as numerous other fields.
I have a form (lets call it frm_Main) that has two subforms: sub_Products (based on the "Products" table) and sub_Datasets (based on the "Datasets" table). On the main form I have a control ctrl_SelectedProduct which is linked to [sub_Products]![p_ID] to see which record in sub_Products is selected / has the focus, and the sub_Datasets subform is linked to this control so that it only displays Datasets records that belong to the selected Products record.
On the main form I also have a number of controls that I'm using for filtering the data in the subforms. For example, I have a control ctrl_Category. I have this control coded so that when the user changes the value of the control, a filter is applied that limits the records in sub_Products to only those that have a p_Category value equal to whatever is chosen in ctrl_Category. If the control is blank, it will show all records. All this works great when if comes to filtering based on fields in the Products table.
Now the problem:
My problem is that I also want to be able to filter based on fields in the Datasets table. For example, Datasets has a field called d_Status. I want the user to be able to chose the status in a control (ctrl_Status), and based on this:
1) sub_Products will be filtered to display only those Products records that have an assotiated Datasets record (or records) that has d_Status equal to whatever was chosen in ctrl_Status
then
2) when a Products record is selected in this filtered sub_Products, sub_Datasets will only show the Datasets records that has d_Status equal to whatever was chosen in ctrl_Status
I know how to do part2. But I have no idea how to get part1 to work. Since sub_Products is currently based on the Products table, which does not have the d_Status field, I have no way to filter it based on that field. Thus, I'm assuming my first step will be to change my setup so that sub_Products is based on a query that combines the two tables (or at least adds the d_Status field).
If I do that, however, I get duplicate Product records. I can't use the query's Unique Values property because if I have a product that has two datasets, one with status "Current" and a one with status "Archived", then those aren't considered duplicates, and the product info is there twice. If I don't have the status field displayed, it shows only unique products initially, but then I can't subsequently apply a filter based on that non-displayed field.
I also tried basing sub_Products on a Totals query in order to utilize the Group By functionality, but I still couldn't get it to work right. Even if I could I don't think that's the best solution, because you can only have 10 fields with Group By, and my Products table has more than 10 fields that I need displayed in sub_Products.
I feel like I'm now just going around in circles and am at a loss of what to try from here. Please help!
Couldn't you add something like this?
Private Sub ctrl_Category_AfterUpdate()
Form_frm_Main.Recordsource = "Select * from Products where p_ID IN(" & _
"Select p_ID from Datasets where d_Status = " & _
Me!ctrl_Category.Value & ")"
End Sub
Alternately, you can access the childform via the parent of the other child form.
This is a non-working snippet just to give you the idea:
Me.Parent.otherChildFormName.Form.Recordsource = whatever
When producing a list of available parameter properties, rather than manually typing each persons name in one by one, is there any way of just populating the data from the table/view which holds all the possible names?
I assume its in the circled box however all that does it let me point to a dataset and then field which I have tried selecting StaffName (being the field that is the one I'm using) if I then run the report it falls over.
Add a new dataset to the report, maybe called StaffMembersDS. The SQL for it might look like:
SELECT Id, Name
FROM StaffMember;
Then assign Name to Label and Id to Value.
BTW if this is related to your last question you're going to run into the trouble that when a user picks a staff member name from the drop down list they are picking only one value. So for your case you might want the Value field to be tied to Name as well as the label. That would allow you to use the query in your last question - SSRS Parameters - which collects related Id values.
SSRS's concept of a query is largely tied to a data set that you define in Report Data.
When you choose 'Use a query', you should be choosing a pre-defined query from Report Data. Of course, the good news is that you can define these yourself.
So let's take your example. You want your possible parameter options to be StaffNames.
Create a new dataset in Report Data. It should return all possible staff names for your report.
Something like:-
SELECT DISTINCT
StaffName,
StaffID
FROM
MyReportViewOrTable
Once you have defined this dataset, you should be able to use it as a source of parameter values.
I am looking at a problem which would involve users uploading lists of records with various field structures into an application. The 2nd part of this would be to also allow the users to specify fields to capture information.
This is a step beyond anything ive done up to this point where i would have designed a static RDMS structure myself. In some respects all records will be treated the same so there will be some common fields required for each. Almost all queries will be run on these common fields.
My first thought would be to dynamically generate a new table for each import and another for each data capture field spec.Then have a master table with a guid for every record in the application along with the common fields and then fields that specify the name of the table the data was imported to and name of table with the data capture fields.
Further information (metadata?) about the fields in the dynamically generated tables could be stored in xml or in a 'property' table.
This would mean as users log into the application i would be dynamically choosing which table of data to presented to the user, and there would be a large number of tables in the database if it was say not only multiuser but then multitennant.
My question is are there other methods to solving this kind of varaible field issue, im i going down an unadvised path here?
I believe that EAV would require me to have a table defining the fields for each import / data capture spec and then another table with the import - field - values data and that seems impracticle.
I hate storing XML in the database, but this is a perfect example of when it makes sense. Store the user imports in XML initially. As your data schema matures, you can later decide which tables to persist for your larger clients. When the users pick which fields they want to query, that's when you come back and build a solid schema.
What kind is each field? Could the type of field be different for each record?
I am working on a program now that does this sorta and the way we handle it is basically a record table which points to a recordfield table. the recordfield table contains all of the fields along with the field name of the actual field in the database(the column name). We then have a recorddata table which is where all the data goes for each record. We also store a record_id telling it which record it is holding.
This is how we do it where if each column for the record is the same type, then we don't need to add new columns to the table, and if it has more fields or fields of a different type, then we add fields as appropriate to the data table.
I think this is what you are talking about.. correct me if I'm wrong.
I think that one additional table for each type of user defined field for the table that the user can add the fields to is a good way to go.
Say you load your records into user_records(id), that table would have an id column which is a foreign key in the user defined fields tables.
user defined string fields would go in user_records_string(id, name), where id is a foreign key to user_records(id), and name is a string, or a foreign key to a list of user defined string fields.
Searching on them requires joining them in to the base table, probably with a sub-select to filter down to one field based on the user meta-data, so that the right field can be added to the query.
To simulate the user creating multiple tables, you can have a foreign key in the user_records table that points at a table list, and filter on that when querying for a single table.
This would allow your schema to be static while allowing the user to arbitrarily add fields and tables.