Example:
I've got payments and every payment has n article in a foreign table.
So now just want to query all the payment data without its article information.
Did i have specify all columns which are needed for a payment or is there a keyword or another mechanism in ormlite to do something like that.
So now just want to query all the payment data without its article information.
So if every payment has articles in a foreign table then you are talking about a ForeignCollection. You can make this collection be lazy loaded (i.e. eager = false) so it will not be queried on at all.
If you are talking about a single foreign object then it will create the object but the object will only have the id field set unless you use foreignAutoRefresh = true. It is false by default.
Did i have specify all columns which are needed for a payment or is there a keyword or another mechanism in ormlite to do something like that.
You certainly can limit your columns in the Payment query but you shouldn't have to.
Related
I'm wondering if it's possible to auto update the User's column('number of posts') if the Posts table updates. The Post entity has a ManyToOne relation with User('userId'). Is there a way to make the User Table "listen" to the Post Table and automatically updates the number of post column, or i need to write it in the post service create function to do so. I'm new to sql so i'm just trying new stuff. I'm using NestJS,typeORM, Postgres and Graphql
#Kendle's answer does work and has the advantage of pushing the computation and complexity down onto your DB server. Alternatively, you can keep that logic in the application by leveraging TypeORM's Subscribers functionality. Documentation can be found here.
In your specific use case, you could register a subscriber for your Post entity implementing afterInsert and afterRemove (or afterSoftRemove if you soft delete posts) to increment and the decrement the counter respectively.
You don't want to duplicate that data. That's the whole idea of a relational database that different data is kept in different tables.
You can create a view if you want to avoid typing a query with a JOIN each time.
For example you might create the view below:
CREATE VIEW userPosts AS
SELECT
user.id,
user.name,
COUNT(posts.id)
FROM users
LEFT JOIN posts ON user.id = posts.user_id
ORDER BY user.id;
Once you have created the view your can query it as if it were a table.
SELECT * FROM userDate WHERE id = '0001';
Of course I don't have your table definitions and data so you will need to adapt this code to your tables.
I am using go and pq to interface with my postgres database.
I have a simple user table which has basic fields. Id, name, type. My auxillary table, admin inherits from user and adds it's own field panel, and another one that is owner and adds owner. Whether that be using table inheritance, or a supporting table.
My question is if I hit and endpoint that points to user/1 at this point I don't know what type of user this person is yet here. I know we can use jwts and other ways to provide this from the front end. I'm more curious about if there is a way to figure out the user and it's type and query the additional fields in one query?
Ie. I hit the endpoint I would Select from users, get the type, then use that type to get the additional fields. So I would effectively be doing two queries on two tables to get the complete data. Is there a better solution of doing this? Is there some optimizations I could do.
I have a Customer Entity with a OneToMany relationship to an Invoice Entity.
In plain old sql i can do "select customer_name,customer_age,[some other fields] from customer, invoice where ... [put some filtering here]", which gets me exactly one record with the fields i need.
In JPA i use "select c from Customer c join c.invoiceCollection where ... [same filtering as above]"
This works, but i get the Customer entity with all its associated invoices.
This is nonsense, because i pull a huge amount of (invoices) data from the database, which i do not need. I need only my customer data with exactly one invoice, as specified in the where clause.
To make things worse, i have to loop over the Customer.invoiceCollection in order to find the one specific invoice needed. This costs me even more time plus it exposes my "where" clause to the middle-tier.
Question: is there a JPA select syntax which fetches exactly one record from a one-to-many relationship, as defined in the where clause?
Things tried so far:
a) lazy loading. This does not work, throws an exception whenever i try to access Customer.invoiceCollection.
Even if it worked, i'd get a Collection with some 1000 entries, which i do not need.
b) changed my jpa statement to "select c,i from Customer c join c.invoiceCollection i where ...". This returns me an array of objects, which i have to manually map to a Customer / Invoice entity.
It works, but it makes the ORM philosophy obsolete. If i perform all the mapping from relational database records/fields to java objects manually in my code, why do i need JPA?
This is one of the most infuriating things about JPA. For example, you NEED the OneToMany side if you want Customer to cascade delete Invoices. In most cases you'd like to tell Invoices to delete itself when a Customer is deleted so that Customer does not necessarily need to know about Invoice.
My suggestion for you is that you keep the OneToMany there but get the Lazy Loading working. In your code, do not access "Customer#getInvoices" directly (unless you really need all of them).
This will allow you to do queries on customers that join to invoices without loading them.
I'm guess the exception you are getting just has to do with transaction boundaries which can be easily fixed.
For a lot of these relationships I often add the OneToMany as a private instance variable but I don't create the #getter method. That way I can use it in queries, setup cascade delete, etc. but I don't provide a way to accidentally load thousands of invoices from a customer.
Oh, and for those queries where you need exactly one invoice with its associated customer you should just do the JPA query on the Invoice and then call #getCustomer on that invoice object. That will be eagerly fetched for you.
If you need exactly one invoice with the related customer, why don't you create a query simply based on Invoice?
select i from Invoice i where [same filtering..]
You should not use one-to-many relationship in this case.
One-to-many relationships are suitable for situations when objects at "many" side are logical parts of object at "one" side (e.g. relationship from Invoice to InvoiceLine).
In you case you need a unidirectional many-to-one relationship from Invoice to Customer, so that you can query it as follows:
select i from Invoice i where ...
Then you can use customer field of Invoice to access Customer or filter by its properties.
In our shop, when we design a database, we typically include auditing attributes for each table (LastUpdateUser, LastUpdateDate, etc). This is common practice, however, I've noticed this becoming an increasing problem when you have tables that "inherit" from other tables, especially using tools such as the entity framework.
For example, if you have tables Customers and Employees, and those tables have a foreign key to table People, then in your entity / class model when you establish the inheritance, you need to change the names for the audit fields because they exist in both tables. Perhaps they need to become PersonLastUpdatedUser and PersonLastUpdatedDate, while the ones from Employees remain as simply LastUpdatedUser and LastUpdatedDate.
When designing tables for inheritance, do you put such audit fields in both tables, or do you just have them in the parent table and update the parent table whenever an attribute changes in a child table?
If you want to use inheritance than those attributes belong to parent table because the parent with related table forms single entity and you track auditing for whole entity. If you for any reason needs those attributes in both tables it should be the first warning that those tables are not good candidates for inheritance.
If you want true auditing, you create separate audit tables that are populated by triggers (never ever by the application or you will miss items that need to be audited).
and they shouw both the old and new value as well as the date and the user or application that made the change.
If you want a last updatedcolumn in each table (which I think is better than having it only in the parenta as that doesn't tell you anything about which of the tables changes last) and you want o use inheritance then you might need to create unique names by adding the table name to lastUpdated. So PersonLastUpdated and OrderLastUpdated, etc.
Or you don't use inheritance.
Is there a way to force the ID value for a new entity in EF when we have an auto-incrementing ID column, i.e. use SET IDENTITY_INSERT behaviour through EF?
Our requirement is that our create form must always show a new, unique ID for the object we're creating on the empty form before it is filled in or saved. The idea is that this ID can be out read to someone over the phone and then the user can complete and save the form after the call is complete. We could reserve an ID by inserting an empty row into the database there and then, but we have unique columns and FKs; instead I've made a 'next ID' table that we increment with locks for safety, and I test this against the top ID in the object table too to be careful. The idea was to then force the use of this new ID when we write back the entity - but I can't see how to get EF to do it.
Is that possible - is it just something I've missed? I don't think the ID even makes it down to the insert so I don't think manually calling SET IDENTITY_INSERT around the SaveChanges would help.
Or do I have to do something else? I can see alternatives:
Change our ID column to not be an identity and take manual control of it all: there's a table ID inheritance here so this is potentially tricky too.
Separate DB ID and user-visible ID into a separate column, and record our unique ID there.
Empty row to reserve the ID, as above; might need some nullability changes, and amending our data read code to ignore these records.
Thanks! This is EF4 (using an EDMX and generated classes not POCOs), and against SQL Server 2008 in case that matters.
Why not use a Guid as primary key. Nothing to do with auto-increment, no concurrency pitfalls etc. You just create the Guid at the moment you create the form. Hand it over to a caller and fill in the form afterwards. When the form is cancelled, no problem. When the form is finished create the entity with the created Guid set the other values of the entity object, apply it to the (a) context and SaveChanges()...
Alternatives that wont alter your schema
Use EF Transaction
You can call context.SaveChanges() and get the autoincremented primary key. Once the process is completed you can commit the transaction. If the transaction is cancelled or there is an error/exception, you can always rollback so you wont have holes/dirty-data in your rows. I suggest you use the singleton pattern and pass the same transaction/context to whatever methods or screens to complete the process.
Just add an additional status: Draft
Save empty form as draft with saved ID, then proceed to edit the form with the information. Once complete save the form as final/ready. If you wont proceed to save the form, you can always recycle the draft.