I would like to know validation is a must, on fields which are not present on the form but are available in the table. Does marking them as NULL in the define_table make them validated only when they are present in the form?
The form validators apply only to forms, so will not affect fields that are not present in the form. I'm not sure what you mean by marking a field as NULL, but if you are referring to Field(..., notnull=True), that executes the SQL NOT NULL statement when the database table is first created (assuming DAL migrations are enabled). That option is enforced by the database itself whenever a record is inserted or updated (via a form or any other method). If a notnull field is left empty, it will result in an operational error from the database.
Related
I've recently received a business requirement for my JSF app to edit rows of a datatable, in the table itself.
The problem: the table is backed by a list of JPA entities, but the editable fields belong to their -optional- associations. So, as an example of such an editable selectOneListbox field, if I do:
<h:selectOneListbox id="rca" value="#{mainEntity.associatedEntity.rca}" converter="omnifaces.SelectItemsConverter">
<f:selectItem itemValue="#{null}" itemLabel="" />
<f:selectItems value="#{rcaOptions}" var="rca" itemLabel="#{rca}" itemValue="#{rca}" />
</h:selectOneListbox>
I eventually receive Target Unreachable, 'associatedEntity' returned null when submitting the table, for those rows where there is no associated entity yet, even if I left the selectOneListbox unchanged for those (null option selected). The questions:
how/where/when can I elegantly instantiate new subentities when submitting the form, only for those rows the user acted on (ajax-less preferably), preventing the error shown above? Forcibly creating subentities in the model for all rows when first rendering the table is IMHO a flaw in design.
How can I programmatically ignore this selectOneListbox -or any other input field- from the entire JSF lifecycle, conditionally, just like if the field never existed in the request? I tried implementing several converters and validators but the validation phase is still trying to get the value reference, no matter what I try, throwing the error shown above
I have an object displaying within a form, a hidden field being related to its PK (field id).
When I create a new object, the field has a null value. Submitting the form, the object is inserted into the DB and it now has an ID, but the field in the page still has a null value.
If a reload the page, now the ID is indeed set in the hidden field.
In my opinion, this is due to the form processing of Symfony: when a create an object, it creates a form, with this form valid the object is saved but the form still uses the data before it was saved.
The question is: how to get the auto-incremented key in the form up-to-date? Shouldn't the form only have a reference to the object? Can't the value be updated?
make sur that you call $entityManager->flush() method after insert and that you bind your form whene you have same data in your request object
$form->submit($request->request->get($form->getName()));
You should have an Entity assigned to your Form by FormFactory. Then Symfony will fill that Entity with submitted values. What's left is only persist the Entity and flush to database.
You can find steb-by-step form submission in Symfony Cookbook
I have two entities: product and category (Symfony 2.3).
I want to create a form in which an user can choose a product by first selecting the category. A user selects the category by clicking on image, then I want to set the image's value into a hidden input, but I don't see how can I change a foreign entity choice list to a hidden input (http://symfony.com/doc/current/reference/forms/types/entity.html).
How can I accomplish this? (how to change form input to hidden)
If I set cascade validation to true, will it for example check if a category really exist. (To prevent putting products with non-existing category from malicious users) ?
Part 1
To do this you need to use a data transformer to do two things:
transform an entity into an identifier that is either a string or integer so a form can render it as a hidden field.
transform the string or integer identifier into the entity when the form is submitted so that the parent entity can be saved with the correct relationship
The symfony docs I linked to above (here too) actually walk though an entire example of using a data transformer with a form.
As a shameless plug (because I believe it is helpful) I have written a little tutorial on using a data transformer for a hidden field with an entity id: http://lrotherfield.com/blog/symfony2-forms-entity-as-hidden-field/
Part 2
If you are using the data transformer then you don't need to worry about malicious users. The data transformer will fail because it will not be able to reverse transform the category from the fake id. In my tutorial the transformer will throw a Symfony\Component\Form\Exception\TransformationFailedException exception.
You can also write a validator (potentially using a call back) if you wanted that checks that the submitted category is real if you want an error to show in the form. Doctrine wont allow you to persist a fake category relationship as the foreign key constraint will fail.
I am trying ORMLite as an ORM for a project I am developing. I am mapping a java class to a table that has some auditing fields (ie. updatedby, updatedtime, etc.). The auditing fields are maintained by the database using triggers to ensure that no matter what front-end the user is using these fields will always be correctly updated when a record is updated.
I need to include these fields in my client application to inform the user when the record was last updated, but the user can't change them. Is there a way to annotate the class so that ORMLite won't try to perform updates on these fields or include them in insert statements. The database will deny an update if these fields are included in an update statement (which is why I can't just write back the original value that was queried from the database).
I tried using the #DatabaseField(persisted = false) annotation on the Java fields, but then they don't get queried at all so the Java object is never populated with these fields.
Basically, I need these fields to be included in SELECT statements, but not included in INSERT or UPDATE statements (equivalent to a #DatabaseField(immutable = true) annotation).
Interesting pattern. ORMLite didn't support the feature at the time but now it does as of version 4.46.
There is now a #DatabaseField(readOnly=true) annotation field.
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.