how can i make update, select and insert query in extbase fluid? [closed] - fluid

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
how can i make update, select and insert query in TYPO3 extbase fluid.
please help me by giving this answer.

In extbase everything is handled by the database abstraction layer. You don't need to do the querys on your own unless you force extbase to that.
For Database things you have 2 files. A Domain Model and a Domain Repository. The Model contains functions like getter and setter, that simply define all fields you want to interact with.
The Repository lets you Request things like a bunch ob rows in table. However most of those unctions are done with extbase magic like findByName or findAll.
If you update, create or delete objects, you use the Repository to get an obkect or the Obkect Manager to create one. Then you can do things with the Model methos like adding a value. If you are done, you use the object Manager functions add, update, remove to send it back to db.
A select queue is pretty much getting a Object with the repository. More advanced functions can be added to the Repository if needed. Then you should read the Documentation on the query function.

Extbase is a backport of some features of FLOW3 framework. It's an MVC framework. When you create an extension using Extension Builder, it automatically creates Domain models and repositories for you. Domain models define your data object and repositories define methods to access your data from the database and returns the applicable domain objects.
You can retrieve data using methods in \TYPO3\CMS\Extbase\Persistence\Repository like this:
$myRepository->findAll();
$myRepository->add($myDataModel);
$myRepository->remove($myDataModel);
Or your can also define your own methods to retrieve data in the repository(which extends \TYPO3\CMS\Extbase\Persistence\Repository) of your Extension.
Check out the following references for further information:
http://typo3.org/fileadmin/t3org/documents/information/referencesheet.pdf
http://blog.typoplanet.de/2010/01/27/the-repository-and-query-object-of-extbase/

Related

Single repository vs Multiple Repositories for multiple tables in Domain Driven Design [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have two tables to fetch the billing rates for standard subscribers vs premium subscribers namely StandardRate vs PremiumRates. The values are populated by the product managers.
The table access is controlled through ORMs i.e., StandardRateOrm and PremiumRateOrm. I am trying to design a Repository that accesses the ORM and retrieve rates based on certain criteria. For example, the zip code range for the users.
I am not able to concretely design whether I need two repository classes vs a single repository class.
Option 1:
I understand that repository hides the storage layer in the DDD and therefore only one repository called as RateRepository is sufficient to access either of the ORMs and return the results. For now, results are value objects since it's a read-only access.
Option 2:
However, while contemplating the SOLID principles (https://en.wikipedia.org/wiki/SOLID). It makes sense to create a Parent class called RateRepository and two child repository classes (StandardRateRepository and PremiumRateRepository) that accesses its corresponding ORM respectively since it adheres to:
Single Responsibility: Repositories have only one reason to
change.
Open/Closed
Interface Segregation
With option 1, it feels like that the interface is not cleaner and also it doesn't adhere to the SOLID principles. With option 2, it feels like it's exposing the storage details in the domain layer.
Are there any known design patterns/rules for solving this?
It is difficult to give a good answer without seeing the domain entity diagram.
Typically rates would be value objects as rates are typically defined by their values and not identities. Ex: any dollar bill is a dollar bill. Just because rates can be persisted it does not necessarily mean they need a repository. Repositories are usually used to work with aggregate root entities.
Even if in your domain rates are entities, a capable ORM or a custom data mapper should be used to abstract the database details (separate tables for different rates) from the object model.

How does view synchronizes with the table [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
Assume I created updatable view:
CREATE VIEW OFFICEINFO AS
SELECT OFFICE, CITY, REGION
FROM OFFICES
Questions:
Will my OFFICEINFO reflect changes if I insert new value to
OFFICES?
How does synchronization work. Is there any predefined triggers on OFFICES table?
Can I switch off synchronization?
What is "pro" and "contro" of having synchronization between view and table?
For an oracle DB, a quick glimpse:
Yes
No triggers, you can imagine a view as a pointer to a table. It reflects the table data in real time, it just store the query
No, but you can use a materialized view as alternative.
Pro: you can use the view as an aggregator from table data (or tables if you use a join) ,it does not occupy space in database, con: if you change table/s structure the view will become invalid until recompilation.
You seem confused about views. A view is just a bunch of SQL code that gets plugged into a query when it runs. The closest equivalent in traditional programming languages is a macro.
So, the view doesn't really exist as a separate entity (with an exception noted below). Each time the view is referenced, the code that defines the view is inserted into the query. Hence a view always shows the latest changes to a table, without using triggers or other mechanisms.
The one exception is materialized views. Not all databases support these. But those that do allow the view to be instantiated as a table. The database itself takes care of synchronization. Your question is not about materialized views. They can be very useful in some circumstances.
I Hope you are working on SQL
Yes. View is just a pre-complied query
(Yes- Partially) .Synchroniztion you have to check manually. If you any operations like (CRUD) with view then Trigger with the Table will intiates
No. The view you have created never support for synchronization.
Synchronization would be fine to get the latest structure(Schema Level) or else it will leads to mismatched Schema in your View.
I can suggest you to read this for better understanding.

Which routes to pick for REST API? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm developing a restful API using NodeJS. To give you a little more insight in my application:
My application has surveys. A survey contains questions which in their turn has choices.
To add a question, you need to provide the id of the survey in the body of the post. To add an option, you need to provide the id of the question.
Now for the API routes. What would be better:
Option 1
/api/departments
/api/surveys
/api/questions
/api/choices
Option 2
/api/departments
/api/departments/department_id/surveys
/api/departments/department_id/surveys/survey_id/questions
/api/departments/department_id/surveys/survey_id/questions/question_id/options
The last one seems more logical because I don't need to provide the id of the parent in the body of the post.
What is best practice to use as endpoints?
I don't think there's a "best practice" between the two; rather, it's about having the interface that makes the most sense for your application. #2 makes the most sense if you're typically going to access the surveys on a per-department basis, and also makes sense in terms of accessing questions on a per-survey basis. If you wanted to eliminate the per-department part, you'd do something that's kind of a mix of the above:
/api/departments
/api/surveys
/api/surveys/survey_id/questions
/api/surveys/survey_id/questions/question_id/options
If you DO want to go by per-department, I'd change #2 so that instead of /api/departments/surveys one would access /api/departments/department_id/surveys ...
But without knowing more about the application, it's difficult to know what the best answer is.
Do surveys contain anything besides questions? do questions contain anything besides choices? The reason I ask is that if the answer to both is no then I'd actually prefer something like this:
/api/departments/ # returns a list of departments
/api/departments/<survey-id>/ # returns a list of questions
/api/departments/<survey-id>/<question-id>/ # returns a list of choices
/api/departments/<survey-id>/<question-id>/<choice-id> # returns a list of options
or something to that effect. Basically, I like to keep the concept of "containers" and "data" rigid. I like to think of it like a file system.
So if the concept ends in an "s", it's a container (and I'd like the route to end with a "/" to indicate that it acts like a folder, but that's a nit).
Any access to "/" results in the element at that index, which of course can be another container. Similar to directory structure in a file system. For example, if I were to lay these out in a file system, I might come up with something like this:
+ /api/departments/
|-----------------/human-resources/
|---------------/survery-10/
|----------/choice-10
The choice depends on whether resources are owned or shared by higher-level resources; whether you want cascading delete or not. If owned (with cascading delete), choose option 2 and if shared, choose option 1.
If a survey is deleted, I guess you want to delete all questions and options with it (cascading delete). This matches well with option 2, because if you delete resource /api/departments/departmentid/surveys/surveyid, you naturally also delete all subresources /api/departments/departmentid/surveys/surveyid/questions/....
On the other hand, if you want the option to share questions among multiple surveys and share surveys among multiple departments, then option 1 is better.
Of course, you can also have a mix of option 1 and option 2, if some resource types are owned and others are shared.

Highlight specific column rows in Microsoft Access [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to present a list of data in an Access query and highlight specific rows which contain certain text. I also wondering if there is any great way to sort up, lets say "Transports" with different orders in groups with spaces between every unique transport.
I believe that I have to make a query and build a form for that with a bunch of macros? Or is it there any easier ways to go? Maybe any great guides similar this to follow? I'm kinda new on Access :)
Thanks for all the help, Cheers!
In Access you first design a database model by creating tables representing your entities and setting relations between them.
Then you create forms and reports based either directly on your tables or on queries. Tables and queries will very rarely be presented to the user directly in an application. This is very different from Excel, where a worksheet is the "database", the business logic (calculations), the user interface and the report at the same time. In Access you separate the data holding from the user interface (data input and reporting). It is also a good design principle to place the business logic in modules and class modules instead of "behind" the forms. Access is an application development environment and not just a tool for entering data.
In forms you can set the Allow Datasheet View property to Yes and the Default View property to Datasheet in order to simulate a table. In the TextBoxes you can use conditional formatting (Menu Format > Conditional Formatting...). Here you can define up to three conditions and formattings that will be applied when the condition is fulfilled. Together with the base formatting of your TextBox this gives you four possible looks for each column.
Grouping in forms is not possible; however, in reports you can insert several nested grouping levels and insert group headers and footers.

Where do you store long/complete queries used in code? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Here's my situation. I've noticed that code gets harder to maintain when you keep embedding queries in every function that will use them. Some queries tend to grow very fast and tend to lose readability after concatenating every line. Another issue that comes with all of the concatenation is when you must test a specific query and paste it. You are forced to remove all of the " that held your query string together.
So my question is, what methods are being used to separate queries from the code? I have tried searching but it doesn't look like it's the right thing because i'm not finding anything relevant.
I'd like to note that views and stored procedure are not possible since my queries fetch data from a production database.
Thank you.
If you follow an MVC pattern, then your queries should be all in the model - i.e. the objects representing actual data.
If not, then you could just put all your repetitive queries in script files, including only those needed in each request.
However, concatenating and that kind of stuff is hard to get rid of; that's why programmers exist :)
These two words will be your best friend: Stored Procedure
I avoid this problem by wrapping queries in classes that represent the entities stored in the table. So the accounts table has an Account object. It'll have an insert/update/delete query.
I've seen places where the query is stored in a file and templates are used to replace parts of the query.
Java had something called SQLJ - don't know if it ever took off.
LINQ might provide some way around this as an issue too.
Risking being accused of not answering the question, my suggestion to you would be simply don't. Use an O/RM of your choice and you'll see this problem disappear in no time.
I usually create a data class that represents the data requirements for objects that are represented in the database. So if I have a customer class, then I create a customerData class as well that houses all the data access logic in them. This keeps data logic out of your entity classes. You would add all you CRUD methods here as well as custom data methods.
Youc an also use Stored Proceedures or an ORM tool depending on your language.
The main key is to get your data logic away from your business and entity logic.
I use stored procedures in my production environment, and we process the rows too...